There has been non at all, they have been on holiday but on this and a number of other problems there has been nothing. The current version is looking like the old CorelDRAW days poor new version spend a year fixing some of the bugs and bring out a new paid for version with many more fixed ones but with even more more bugs for the next year. Many of the current problems are years old and never been fixed. I have had in V5 one bug fixed, another said to be due before March with a third left hanging that’s years old.I think the problems were made worse by the DAM and to me it look like the same problem that lead to the DXOone mess of not taking any notice of anything said about what they are doing or going.
1 Like
@Joanna, @platypus, @John7, @jch2103 Just a quick update to apologise for not joining in this conversation yesterday. The central heating is back together, new header, re-arranged overflow (still need to duck), new vent (now no need to shimmy round it) but no heat flow i.e. the boiler and pump get the hot water only so far!
Talk with the plumber Thursday night about ideas to troubleshoot so removed pump and choked with baked on crud, new pump should arrive today! However, cheap spare pump didn’t achieve much so removed return pipe at the back of the boiler and removed skin on right arm about 2.5 x 1 inch in old Imperial in the process, ouch!! No baked on crud on pipe so back to the “drawing board”.
This has somewhat pre-occupied my mind and time and I am now feeling very tired but will try some tests along the lines of Joanna’s tests in a few minutes.
With respect to recent DxO reaction to the forum posts it does seem a little quiet but hopefully that will change soon and I don’t regret buying the upgrade, I simply want the product to work the way I feel that it can (and should). However, this release has been a shock to many users who have never really considered the upgrade process to carry any risks!
I may be partly to blame for the keywords being put in the DOP because I did suggest they might be useful as a source of data for recovery in one of my posts during PL5 beta testing, but I doubt it!
In truth the risks with replicake data is just that, plus when you have replicate versus replicake which one takes priority over the other. However, personally I would always prefer having too much data versus too little, providing I then have control over what is used i.e. one versus the other or the more complex additive situation, i.e. “this” from here plus “that” from there etc…
This is not a particularly complex situation just that it seems that someone(s) got it wrong.
On a high note the tests I was writing up at the same time that Joanna made her post showed DxO able to follow the rules perfectly (I think) with respect to ‘Ratings’ held in either the ‘xmp’ sidecar or the ‘xmp’ data embedded in the RAW with only the the deletion of the sidecar file requiring an ‘F5’ refresh (do you remember the ‘F5’ @jch2103?).
There remains a test to substitute an old sidecar where FRV, PM and DxO are displaying the embedded ‘Rating’ to see how they all react my hope is that it will be ignored but if the rule is always sidecar over embedded then …
@Joanna, @platypus, @John7, @jch2103 Oh dear I have “dissention in the ranks” (of the programs)!!
I changed the name of an “old” sidecar (back to .xmp) after checking that all the programs were inline and using the embedded ‘Ratings’.
PL5 and FRV used the sidecar ‘Rating’ value but PM stuck with the embedded value, so I started up Imatch and this also chose the sidecar value. please note that Imatch was started after the changes were made and not before!! Running 5 applications across three screens is a nightmare!!
- Changed embedded Rating = 1 in PM and all tracked the change ignoring the ‘Rating’ = 3 in the sidecar file.
- Changed ‘Rating’ = 2’ in FRV and all tracked the change, i.e. all using sidecar at this point!
- Changed ‘Rating’ = 0 in PM and all tracked the change
- Saved the ‘xmp’ sidecar file with name change and noted that Rating=0?
- Checked values of rating in other programs still 0
- Renamed old sidecar and refreshed all and only FRV shows Rating = 3!
Yet more testing required with respect to changes while running versus detection at startup (the latter is a testing nightmare because the Sticky Previews are use to capture the different programs all need to be set up again after every restart)!
Ah! So you’re the culprit 
Well, however it came about, it might have been useful if somebody at DxO hadn’t created the present WOM (write only memory) model, where stuff gets written but never read.
And I still don’t get why metadata needs writing to a DOP file at all. Surely, once it’s written to either the original file or an XMP sidecar, what are the chances of data loss that any other DAM wouldn’t be susceptible to? And if DxO want to write it to the database, for indexing purposes, then, at least, the data will only be in two places instead of three and if the database corrupts, it can always be rebuilt from original files and/or XMP sidecars.
I think someone got into the “make a change, write it to the DOP” mentality without thinking about separation of concerns.
Don’t shout too soon
I see your tests and I’ll raise you some of mine 
Seriously, I’m just in the middle of documenting how a JPEG file gets treated and, in the process, I’ll try and put together a testing strategy, hopefully covering all possible possibilities, both for JPEG and RAW/XMP scenarios, if that will help?
Now to read your latest post.
1 Like
My posts are so long I am not sure anyone reads them anyway!!
In truth there is a problem even with ‘xmp’ sidecar versus embedded ‘xmp’ let alone DOP sidecar versus embedded PL5db! The main problem is the proud insistence of DxO with respect to immutability pre PL5.
So we have the need to store keywords, Ratings (Rank) and the Tag somewhere in PL4. The keywords went into the database along with the Exif data and the ‘Rank’ and Tag went into the database and the DOP. Hence the photo carried the Exif etc. and the DOP carried the editing, Rating (Rank) and Tag and the keywords went down with the database!!
It is actually logical that you extend that philosophy to the keywords so they don’t sink with the ship (database) except that with the change in immutability the keywords already have a “universally” accepted sidecar in the shape of the ‘xmp’ sidecar for RAW images and the image file itself for RGB images so the DOP becomes redundant for that role!
Basically putting the keywords in the DOP was at least a release too late and the Ratings could have been removed from the DOP in PL5 because they are either in the image file or the ‘xmp’ sidecar but what would have happened to backwards compatibility!? In truth the final PL4 release should have included as much backward compatibility with PL5 DOPs as practical (in which case all the elements should still have been in the DOP etc. etc.).
As far as I can tell the Tag has no ‘xmp’ counterpart and PL5 does not use the “pretty” colour scheme at all!!
With PL4 the final test shows Rating=3 taken from the sidecar (the PL5 DOP shows Rating=0) and all the ratings are in a “pretty shade of yellow”!
Further Update:-
I changed Rating=5 in PM and PL4 immediately detected and showed the change!
On restart PL5 found Rating=5.
Close PL5 set Rating=2 in FRV (i.e. sidecar Rating=2).
On restart PL5 found Rating=2 but without the pretty yellow!
You think your posts are getting long? Try this for size…
Tests with Rating for JPEG files
Start with clean JPEG
Test with FRV
Set Rating in FRV to 2 - XMP file gets created with Rating of 2 written - original file not touched
Open JPEG in Adobe Bridge - no rating detected - presumably because Bridge never expects to read from XMP for a non-RAW file
Open JPEG in PL5 - no rating detected - presumably because PL5 never expects to read from XMP for a non-RAW file
Rating in JPEG has not been changed - delete XMP file as irrelevant and don’t use FRV to rate JPEGs
Using PL5 for JPEG files
Set Rating on JPEG file in PL5 to 3
- Rating of 3 written to JPEG file, both to
exif:ratingandxmp:ratingtags - this is wrong, onlyxmp:ratingshould be written - DOP file created with Rating of 3 written
- XMP file still contains Rating of 2 - presumably because PL5 never expects to write to XMP for a non-RAW file
- nothing written to database
Close PL5, delete DOP file and database
Reopen PL5
- Rating is correctly read from JPEG file
- database is updated from JPEG file - thus proving that it never needed to be written to the DOP file
Conclusion
Apart from unnecessarily writing Rating to the legacy exif:rating tag, PL5 handles the Rating of JPEG files better in that it, at least, writes it directly to the JPEG file, thus preventing data loss in the event of DOP file and database loss. It also means that any other app, including PL4, can read the Rating
Interaction between PL4 and PL5 for JPEG files
Use ExifTool to set Rating of JPEG to 5
Open JPEG in PL4 - Rating of 5 is correctly shown
Change Rating to 3 in PL4 and close PL4
- DOP file is created and contains a Rank of 3
Close PL4 and open JPEG in PL5
- Rating is shown as 5
- DOP file still contains a Rank of 3
Make an image edit to the JPEG in PL5
- DOP file now shows a Rating of 5 and the Rank of 3 has been deleted
Reopen PL4
- even though I have changed the Rating in PL5, PL4 continues to read the Rating of 3 that it wrote and which is still in the PL4 database - presumably because the DOP file no longer contains the Rank.
If I then close PL4, delete its database and reopen it, PL4 then shows the Rating of 5 that PL5 wrote to the JPEG file.
N.B. PL4 only writes and reads Rating from either the DOP file or the database. Delete both of these and all record of Rating is lost.
I remain convinced that reading a JPEG file that has a PL4 DOP, in PL5, should instantly provoke:
- The writing of the Rank found in the PL4 DOP to the JPEG file
- The DOP should then be updated to remove the Rank
- The Rating should not be written to the DOP because it is totally unnecessary and will not be used from then on.
Further tests on interaction between PL4 and PL5
Start with JPEG that contains a Rating of 5 but no Keywords
Open PL4 and add two keywords “Bacon” and “Buttie”
No DOP file is created and the keywords only exist in the database
Make an image edit and a DOP file is created but:
- the Rating of 5 from the JPEG is ignored
- a Rank of 0 is written instead of the anticipated 5 from the JPEG Rating
- no keywords are written
Close PL4
Open PL5 and the Rating of 5 is visible but the keywords are not recognised.
Conclusions
- If a JPEG file contains a Rating, PL5 ignores the Rank from the PL4 DOP file, so any PL4 ratings are lost
- PL5 can’t read any keywords written by PL4 and I can’t find any way of circumventing this.
1 Like
Thanks for testing all these variants, @Joanna and @BHAYT. You put a lot of effort into the half-baked version that DPL5 is now, and I do hope that DxO will draw the correct conclusions and do the right thing - or your efforts might be spent in vain.
If you remember how DPL5 was advertised, there was no mention of asset management (imo), which leads me to conclude that DxO considered this featureset as unfinished and unworthy for communication, although, if done properly, it would and important stepstone for all the folks who want to move away from Adobe subscription software.
Let’s hope that we’ll get some kind of feedback by @CaptainPO next week.
1 Like
This may relate, I take jpg’s on my phone which have been processed in PL, 2,3,4 and now 5. These have keywords added after processing in PL by putting them into Photo Supreme then exported from PL.
Since version 5 has changes how copyright and keywords are treated I have now found PL5 can’t export jpg’s with keywords added. You get unknown error message. Not just ones taken and then processed in PL5 but any jpg processed in earlier versions of PL. There is NO problem with RAW images. I take it this is a bug and it’s a major problem for those of us who use phones which are mostly unsupported in PL so have to use jpg.
This is the bug that support say a fix is due befor March.
I found it intresting that some of us found a bug in Photo Supreme, emailed them on Thursday, had a beta fix to try Friday which worked and relesed Friday afternoon. DXO count fixe times in months not days or hours!
@platypus you are welcome to the testing effort from my part; if PL5 had standalone faults that is one thing but for those moving from PL4 to PL5 if they start losing “their investment” then that is an entirely different issue!!
Could you take a single example and write down the precise steps you take from taking the picture, processing it, keywording it, etc, through to exporting the JPEG?
Joanna I took one and it exported. The fix must have been done as I went back and tried the examples I sent support to which they which they said
“Hello,
Our team identified your issue.
We will delivered a fix for one of our future update, in March for the latest.
Thank you for your patience.
Regards,
Fernando - DxO Labs Support Team 1”
Isn’t it nice when they don’t tell you something is fixed, so I can go back to processing everything in Photo Supreme rather than just the RAW. Been back and tried a number of others that couldn’t export befor and pleased to say they now export OK.
If any use, what I do is load imiges into folder, run Photo Supreme add keywords. Backup onto NAS and open and edit in PL. I export to a test folder to check results, go back change where needed and remove unwanted ones. Rerun Photo Supreme to remove deleted photoes, if needed. Export to flicker and rerun backup unto NAS to remove unneeded ones and add dops and backup to desk HDD and laptop (so its a mirrer of PC when in use away).
Joanna (@Joanna) you can use FRV for JPEGs but you need to set the options to not create sidecar files as follows:-
Now there are two potential problems
-
The differences between Win10 and MAC
-
I am using a Beta version of FRV to include changes to avoid going back to the ‘File’ ‘Reload’ menu to Reload/Refresh a photo (e.g. the Ratings) it is now available on the Thumbnail (if you ask you may get if you don’t you never will, so I asked) etc. Unfortunately I had too many variations of FRV that I deleted all but this Beta version so I do not know what is available as standard, oops!!
The reason for my test group of 3 JPGs and 1 or 2 RAWS is to cover embedded xmp (JPG), sidecar xmp (RW2) and with PM I can force embedded xmp with RAW (RW2). The 2 RAWS are RW2 and ORF, RW2 sets ratings to 0 in camera and ORF does not.
Update 1:
Looking at the options more fully there is one to specify how to handle when both external and embedded are present. If only all software was as customisable!!
I’d call it a no-go…and pull the update until it’s fixed.
1 Like
@Joanna, @jch2103, @John7, @platypus just been doing part of the Joanna tests but added an element where I went along my images using each piece of software in turn to see what happened! I have already experienced a problem with the beta version of FRV and that reared its head twice and IMatch got stuck on two occasions while attempting to update the RAW (I believe attempting to update the sidecar) but I could not clear the error by getting IMatch to re-scan given that it was IMatch doing the update in the first place!!
The problem only cleared when another program did the updates!!
Two error reports to write and the issue will be put down to interference between the programs (they are all running at the same time and actually if well written that should not cause a problem), i.e. a program not being able to secure a lock. While that may be true the standard procedure for such a problem is to wait and try again and again for a timeout limit with an increasing wait time between attempts.
Who is causing the write delays in the case of IMatch and Read delays in the case of FVR (if such errors are actually occurring) I am not sure but PL5 worked fine and it detects the changes “immediately”, PM detects when forced to refresh but also detects automatically but over a longer time period than PL5. It is possible that PL5 auto detection is causing problems but it should only be reading when IMatch decides it has a write error!!
I will repeat the IMatch test but dropping different programs out of the mix at some point.
@Joanna @John7 @platypus @jch2103 What a mess I got myself into trying to test Joanna’s PL4 to PL5 issue because I tried using my original 4 photos which were already known to PL5! I managed to hang PL5 3 times, discovered why I have never stuck with any DAMn DAM when deleted entries are preserved by IMatch thereby cluttering up my “nice” display.
The display has two file managers showing the DOP, they were set up for the RAW testing and one was to monitor the DOP while the other monitored the xmp sidecar.
PL4 to PL5 migration via DOP works on Win10:-
I followed Joanna’s procedure from PL4.3.6.32 Ghosting Ratings for Same image in different directories (Win10) - #21 by Joanna and it worked as my other tests have indicated Lost all ratings in PhotoLab Elite 5.1.0 ??? - #18 by BHAYT where when moving from PL4 to PL5 the DOP was taken in all cases as the starting point for PL5, when present. Where in Joanna’s tests PL5 takes the rating as 5 from the photo in my test it took the ratings as 3 from the DOP! Is this a WIN10/MAC difference or pollution in my database so delete DB and test again!
For some bizarre reason PL5 wants to make my backup for PL5db in the default location for the PL4 database (something I did or didn’t do!?). I messed up the tests and managed to hang PL5 with an essentially empty database on a 1 photo folder and have lost the will to …
I just repeated the test and PL5 took the value from the PL4 DOP, changed the photo setting Rating=3 and HUNG, HUNG, HUNG yet again @sgospodarenko
@BHAYT, do you still have a database that has not been spoilt by your tests?
If you do or think you do, you can restore everything based on that reference.
Depending on what version of DPL this database is coming from, the restore is more or less simple along the following steps:
- Open the “reference” version of DPL (the one with the unspoilt database)
- Export settings files (.dop sidecars) for all spoilt image files.
- Back up the database, then quit DPL
- Open DPL5, point it at an empty folder
- Restore the database from DPL (reference) - DPL can restore DBs from earlier versions
- Quit DPL5
That’s it, you should now be back with everything okay again…but as with every restore, things you did after the last “correct” use and backup will be lost.
So far, DPL has never destroyed any user data with new releases. Nevertheless - and based on recent experience - it’s important to back up the database before updating. If I’d use DPL as my main photo application, I’d regularly backup the database, as I backup Lightroom’s catalog.
I also hope that DxO will add database management features really soon.
1 Like
@platypus Thank you for the info. I have already done that successfully and also imported a PL4 database straight into PL5.
As a matter of some urgency we need:
-
Add New database command. Whether there is any notion of co-existence in the implementation is up to DxO. I have read numerous posts elsewhere about 1 Lightroom Catalog versus many and well understand the benefits and risks associated. The main disadvantage is the lack of a spanning search, i.e. you can only search what is in the database you have open rather than what is in all databases. Welcome the DAM!!
-
Add an expunge photo(s) command, i.e. delete from the database but not disk. The bulk of the logic to keep indexes etc. in line is already there in PL5 but (just) stop short of deleting anything on disk BUT add an option to delete (or not) the DOP at the same time. Doing so risks losing all edits from both the database and the DOP but it is a useful option in a very tight corner and the user can make presets from the edit settings to re-apply later.
Next step options:-
- Allow deletion of directories.
- Allow Expunge of directories (from database but not from disk). No option to remove DOPs necessary (I believe).
Not entirely true particularly if you consider why I started this topic in the first place, the PL4 ghosting can have a knock on impact of the Ratings in PL5 (if Sync option is on)
We both mean the same thing: Before what we see now, DPL played nicely with assets. DPL5 updates left that track though.