Rotation not kept in dop’s why?

Bryan, I am having enormous problems decoding your posts, screenshots, etc.

In this screenshot, you are showing the Keywords tag, in the highlighted row, as containing different values than the Subject tag. What did you do to achieve this? Neither my app nor PL5 writes the Keywords tag to the either the original file or the XMP sidecar. However, PL5 does write it when exporting, even though it is not present in the original file.

In fact, the IPTC palette in PL5 has no mention of the iptc:Keywords tag that it goes on to create on export.

Which one? Both are possible, simply by checking or unchecking the appropriate rows in the hierarchy.

Which is precisely what all keywords are - just a flat list. It is only when those keywords are organised into a hierarchy, that the need to record those relationships arises.

  • In the database, a parent ID column indicates the parent keyword
  • In an XMP record, the lr:hierarchicalSubject tag should contain the relevant hierarchy

At the moment, PL5’s handling of hierarchies is, to put it mildly, chaotic.

I created three hierarchies in my software…

  • Couleur > Orange
  • Fruit > Orange > Satsuma
  • Entreprise > Télécommunications > Orange

Then I applied them all to a RAW file.

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Couleur</rdf:li>
               <rdf:li>Entreprise</rdf:li>
               <rdf:li>Fruit</rdf:li>
               <rdf:li>Orange</rdf:li>
               <rdf:li>Satsuma</rdf:li>
               <rdf:li>Télécommunications</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Couleur</rdf:li>
               <rdf:li>Couleur|Orange</rdf:li>
               <rdf:li>Entreprise</rdf:li>
               <rdf:li>Entreprise|Télécommunications</rdf:li>
               <rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
               <rdf:li>Fruit</rdf:li>
               <rdf:li>Fruit|Orange</rdf:li>
               <rdf:li>Fruit|Orange|Satsuma</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

And, opening the file in PL5, the palette shows…

Capture d’écran 2022-06-03 à 15.22.02

Unnecessary duplication of keywords in the keywords field but the hierarchy looks fine.

No problem at all.

However, if I remove some of the parent checked items in the hierarchy…

Capture d’écran 2022-06-03 à 15.15.59

… I get something altogether wrong in the XMP file…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>Orange</rdf:li>
               <rdf:li>Satsuma</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>Couleur|Orange</rdf:li>
               <rdf:li>Entreprise|Télécommunications|Orange</rdf:li>
               <rdf:li>Fruit|Orange</rdf:li>
               <rdf:li>Fruit|Orange|Satsuma</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

Unless I use PL5’s own search mechanism, there is no way I can search for files that contain a specific hierarchy. The only externally searchable keywords are Orange and Satsuma.

Added to which, using the PL5 search, it is totally impossible to search for Orange as part of multiple hierarchies.

@Joanna can I take this an item at a time!

Sorry about the screenshot clarity or lack thereof! All the tests that I did for my original spreadsheet were

  1. Add keywords to four images in an application (PM, LR C1 etc. etc.) of
    1 - animal, mammal, bear
    2 - animal|mammal|bear
    3 - animal|mammal|bear|brown bear
    4 - animal, mammal, bear, animal|mamal|bear
  2. Then use PL5 to discover the metadata (keywords) put there by the respective software and export those images as JPGs.
  3. Compare and contrast the keywords inserted by the software compared with the keywords output from PL5 as part of a standard JPG export (i.e. the outputs from step 2) and do this for PL5.1.4 and PL5.2.1.

What happened pre the change was that every keyword in a hierarchy would be output by PL5 as a ‘dc’ keyword and as a consequence an"hiatus" “raged” in a least 2 topics with complaints that PL5 had created all these extraneous keywords! So PL5 changed the keywords created so that after the change only the “lowest” key is now placed in the ‘dc’ key on Win 10! Sadly this is not going to fix the complaints nor is it going to meet your requirements for what should be in the ‘dc’ keywords!

I reran the tests using Photo Mechanic to create the keywords in a JPG and PL5 accessed this original JPG, i.e. in this case I did not export from PM, arguably there are two sets of tests that need to be done here;

  1. The original image with keywords added by software.
  2. The image exported by the software after the keywords have been added.

I believe in the spreadsheet I used method 1 for all except C1 where I had to export!

In my snapshots from both PIE and Exif Pilot the ‘keyword’ column relates to ‘IPTC’, ‘Subject’ is ‘dc’ and ‘Hierarchical Subject’ is ‘hr’. Although I have doubts about where PIE and Exif Pilot locate the 'keyword fields, I just checked with XnViewMP in its ‘Exiftool’ column and it shows the data exactly as do the other two programs!

I repeated the test twice using a different option in PM ‘preferences’, the second test uses the “_AB” image and the ‘Preference’ change removes the hierarchical keyword from the ‘dc’ entries!

Hopefully this snapshot is clear enough to show the two images “keyworded” in PM and the outputs from the two versions of PL5 and the changes to the ‘dc’ fields in particular!

OK. Let me stop you right there. Apart from the first item, the “keywords” you are adding are not and never have been valid for adding to the 'dc:subject` tag.

animal|mammal|bear is one keyword that just happens to contain pipe symbols. It has no implicit hierarchical context unless that context is inferred, written and read by one particular software. It has no place in correctly defined metadata, regardless of the software as it doesn’t comply with MWG Guidance.

From that point on, all your tests become irrelevant and DxO has no obligation to consider reading, editing or writing anything derived from such “keywords”.

Amazingly, PL5 does, sort of, cope with animal|mammal|bear

Capture d’écran 2022-06-03 à 18.02.35

… but it certainly does cope at all correctly with animal, mammal, bear, animal|mamal|bear

Capture d’écran 2022-06-03 à 18.00.32

… with the database looking like this…

As you can see, and as expected, the database bears no resemblance to the full list of keywords placed in the dc:subject tag.

Do you really expect DxO to expend time and effort catering for non-standardised inputs from other software? There is an old acronym - GIGO. Any app that allows separators like <, > or | in the input field, without parsing it into separate keywords before storing it isn’t worth considering.

PL5 might parse text like animal|mammal|bear correctly, but it still doesn’t write the flattened keywords from the lr:hierarchicalSubject tag correctly to the dc:subject tag.

John, I have not yet read all of the responses to your question/issue, but I have had NO SUCCESS with DXO in past support requests to undertake what is needed for DXO PL to reflect processing (and other) changes made to images in the same file folder when that file folder of images is used and processed on more than one computer. In my case it is a win 10 laptop and a win 10 desktop. DXO has told me that this is not a need for most photographers. The only recourse you and other DXO users have is to launch an effort to get this major change incorporated in newer versions of DXO PL.

Others with a more technical background can explain why you are having these problems. The best I can do is to state that .dop files created on one computer are not (completely) transferred with the images when those images are processed and view on another computer.

The DXO software architecture requires me to limit my processing on my laptop (where I first view and cull the files.) And do the processing on my Desktop (my second stage processing.) I would like to move the file folders back to my laptop, but that is when I incur all sorts of cross processing problems.

I will state this. If I change the rotation of an image on my laptop, that rotation change is recognized when I view the image on my Desktop.

Your problem might also be related to a setting in your camera. For Nikon cameras, it might be under Playback.

@joanna @sgospodarenko Well I wouldn’t trust me to “design” the database, the ‘ItemsKeywords’ structure listing was just above the above comment in my post but I still incorrectly suggested that the new fields I was suggesting should be added to the ‘Keywords’ structure!?

The new fields belong in the individual “incarnation” of each keyword used, i.e. the new fields would belong in the ‘ItemsKeywords’ structure not the ‘Keywords’ structure if such a scheme was implemented.

@Joanna I am aware of your knowledge of the guidelines but the “guidelines” that I “follow” are based on empirical study, i.e. whether what I am doing and the response to my actions, by software, is typical or atypical!

Entering the hierarchy using the top-down syntax of animal|mammal|bear is accepted by every piece of software that I have used and, where the software actually “understands” hierarchical keywords it is used as it should be (more or less!). The bottom up syntax bear>mammal>animal or animal<mammal<bear seems to be acceptable to a number of packages but I have not tested them all with this syntax.

I do not for one moment believe that the style of data entry to PL5 has one iota of impact on the product or the problems that I am writing about and if PL5 is wrong it is in “good” company because the rest do it the same way (rules or no rules).

However, continuing our discussion in this topic is unfair on @John7 who will be receiving alerts every time a new post is made so I propose to start a new “bug” topic with respect to the changes made to PL5.2.0 keyword handling which will include the latest version of the spreadsheet (almost complete).

What I did discover is that there are 3 options available for formatting hierarchical metadata in IMatch and one of those exactly matches the new format being used by PL5 but at least IMatch gives you options and doesn’t change the product between two intermediate releases with zero explanation for the rationale and zero documentation, in fact IMatch’s documentation is so complete that I am likely to miss something significant because of the shear amount of detail on offer!

I will keep you informed when the new topic is posted.

@Photoman43 I am concerned by your post in particular the statement that

and

Please be more specific in both cases since I have tested the issues extensively and written about them, including a procedure that should enable you to move from one system to another, a directory at a time without experiencing problems, namely Synchronise PhotoLab - #26 by BHAYT .

Related problems are also discussed in What is the best way to move a folder of photos with their respective *.DOP and *.XMP files? - #15 by BHAYT

At the time I wrote the procedure it was just theoretical but I have subsequently tested it and it worked for me on Win 10)! Indeed if you are careful you should be able to take the images back and forth between two or more systems as many times as you want!

In order to see if you are “losing” any data you could conduct the following test (incidentally you don’t say what type of images you are using nor what versions of DxPL you are transferring between)!

  1. Create a new Directory, e.g. TEMP, and copy a few “typical” images to that directory, on your laptop.

  2. Apply edits that you believe you are losing in the transfer to any or all of the images.

  3. Any ‘Rating’, ‘Rotation’. ‘Keyword’ changes you make must be “flushed” back to the image xmp metadata, embedded for JPG, TIFF or DNG, or xmp sidecar for RAW by e.g. ‘File’/‘Metadata’/‘Write to image’.

  4. Copy the directory (contents) from one location to another on the laptop e.g. from TEMP to TEMP-NEW, where TEMP-NEW is “unknown” to DxPL.

  5. Discover the directory in DxPL by opening it and all the edits, metadata etc. should be intact! If they are not then please re-post here.

  6. If it works then use the procedure to move TEMP to your other machine and check.

  7. Feel free to move them back to the laptop using the same procedure.

  8. I have run into problems with deleted images throwing up multiple Virtual Copies for images that I have just deleted from the directory! This only seems to occur when the directory I have made the deletions to is actually open when I transfer the “same” data back into the directory and is definitely a “bug”.

NEVER copy files from one machine to another into a directory that has the same name and same images as one on the target system, otherwise Virtual Copies will be created because the incoming DOP Uuid will not match the Uuid on the receiving system, at which point DxPL leaves the existing database copy as the [M]aster and imports (probably the later updates) as Virtual Copy [1]! Although I and others have asked for an automatic command to elevate [1] to be the [M]aster who knows if that will ever arrive.

I have a procedure to enable it to be done but it is very laborious, i.e. it is way better to avoid the problem entirely. If it does happen you are better to show all the Virtual copies via the thumbnails and delete them (the VC’s only) and work out what went wrong with the “move” procedure and execute it again!

As far as I know this Virtual Copy issue is the only problem moving data between systems, excluding any “bugs” you may have turned up!? You should not be losing data unless it is metadata which you have not “flushed” back from the laptop DxPL database to the image file prior to transporting it (except for the DxO ‘Tag’ field where I believe there is still a bug, i.e. this still resides in a PL5 DOP and PL5 should read it back from the DOP but it isn’t doing that!!)

I copy between laptop and pc with problem. I have a backup program on both which exacy copies which ever way I moving them. Both sides have the same pl setup and have no problems. I copy both ways as my laptop is not very good with deep prime and on the pc monitors I can tweak them them copy back as I might delete some after getting on good displays (not very good eyesight now)so both are exacy the same. The only fify I’d I have all the imiges on the pc buy only last 3 years on the laptop.

@John7 I presume this was supposed to be “without problem”? My favourite comparison software is Beyond Compare and comparing two directories between two systems is easy but if I compare TEMP to TEMP on each system and both TEMP directories have already been “ingested” into the DxPL database then the incoming DOP will present with a different Uuid to the database entry and a VC will be created.

If I copy to TEMP-new where TEMP-new is just that (new and empty) then the copy will be fine. If I change TEMP to TEMP-old and TEMP-new to TEMP then all is O.K…

The only way a simple compare and copy can work is if the incoming DOP once came from the system to which is being copied and still has the same Uuid!

@John7 please explain your exact procedure so that I can determine how you are avoiding unwanted VCs. e.g… getting the copy to the laptop, what happens on the laptop, what the compare software shows etc. or are you carrying the database with the copy?

Just copy imiges (used Syncovery for years for copying between PC’s, server and now NAS ond off site to son’s server.) and related files (RAW, jpg xmp dop)no problems I use a different dam and delete the pl data base at times. Never had virtual copies of problems, just finished copying over as we are away for a few days. Dam updated itself when the new imides are imported and pl opens with imorts and/ changed. As I delet the database sometimes the loss of imiges doesn’t become a problem. I don’t use ranking of anything else that uses the database by chance, which is why this topic started rotation used to work but with the changed in 5 it doesn’t now except now I know to use fastview and rotation is no problem when using phone JPGs (used when have macro and telephoto on the two cameras I use the phone for wide angle). I copy direct between laptop and PC but not always, somtiimes from one of the backup usb drives I use when away (also keep both updated). All I have setrup belowe, to change direction change copying direction.

Bryan Thomas asked me to respond. All of the emails and documents are at:
Two Computer Problems with DXO PL 5.pdf (2.5 MB)

Your request #310494 has been updated. Please respond directly to this email or follow the link below :
http://support.dxo.com/hc/requests/310494

If you cannot access that I have attached a pdf file that was in my email to DXO Support. Fernando from the Support Team was my contact.

@photoman43 I would say “thank you” for the pdf of your workflow, how many of the issues I can help with remains to be seen! You included the pdf in an open forum so I have made the presumption that it is O.K. to extract any elements that I want from that document and reproduce here!

  1. Download Nikon NEF images from card reader to my Laptop with Downloader Pro from Breeze
    Systems. XMP files (sidecar files) are created at time of download. This info is appearing in DXO
    (BHT) PL5 as it should!!

  2. Review images in Nikon software or DXO PL5 and delete images not needed. Add additional
    keyword data if needed using PL5. Occasionally process some NEF images and make Jpegs and
    Tiffs. (BHT) A rather mixed workflow but who am I to criticise, unless this mixed processing is losing valuable metadata!? Are the TIFFs and JPGs sometimes created at this stage coming from PL5 or the Nikon software

  3. Copy image file folders to external hard drive and then copy file folders to Desktop with a larger
    monitor for additional culling, key wording, star rating and processing. (BHT) Providing the directory name is new to the Desktop system this should be fine!

  4. Complete key wording of images on Desktop using DXO PL5. This usually means adding additional
    keywords and changing some created during download. (BHT) This also should be fine!?

  5. Star rate images in DXO PL5 on Desktop only.(BHT) This also should be fine!?

  6. Process images in DXO PL5 and NIK Collection 5 on Desktop. Export Tiffs and Jpegs as needed
    using PL5.(BHT) This also should also be fine but if the export is to the same directory or a directory that you explore with PL5 then these images could acquire DOPs!?

  7. For some trips and projects, copy file folders with processed images from Desktop to external hard
    drive for copying back to Laptop. (BHT) now you are potentially asking for trouble! If the images go back into the same directory in the same position in the same directory structure as they came from on the laptop then Virtual Copies will most likely be the result!

This was discussed at great length for over the period of a year in the following topic (these are my responses) Unwanted virtual copies - #86 by BHAYT and Unwanted virtual copies - #91 by BHAYT and Unwanted virtual copies - #92 by BHAYT finally closed the topic!

The reason is very, very simple (but annoying) iff(if and only if) an image with a DOP is presented to a PL5 system which already has an entry in its database for a file with the same name in the same directory then the Uuid in the DOP associated with the image will be compared with the Uuid in the database entry (matching the image) and if they are not identical then the database entry will be preserved as the [M]aster copy and the incoming, non-matching DOP data will be preserved in the database as a Virtual Copy [1] - in your case VC[1] will typically contain the latest edits!

A number of us have suggested options for resolving this problem during the re-discovery e.g. of providing an import option or an option to “promote” VC[1] to the status of the [M]aster etc. etc. but …

The only real solution is to avoid the problem altogether!

  1. Have a workflow which changes the name of the directory when you have completed a stage of processing. This newly named directory will then be “new” to the laptop and no VCs should be created except when it goes back to the desktop but it has been through another stage of processing so that should also have a new name and you will quickly consume the hard drive!!

OR

  1. Change the name of the old directory in PL5 to -OLD or - or whatever you choose on the receiving system!.

  2. Copy the (Desktop) directory to the laptop (receiving system) with its original name and discover in PL5, it should be intact with no ‘Virtual Copies’. I say should because although this has worked for me in testing I have found issues when doing something similar.
    1 - So one additional step might be to shut down PL5 on the laptop after the name change of the original directory
    2 - Copy the directory from the USB drive to the laptop with its “original” name.
    3 - re-open PL5 and navigate to the original directory which should be in-place with all the edits from the desktop and no VCs (hopefully)

  3. If all is O.K. then the old directory can be deleted at your leisure but keep it as an insurance until you are sure that all is O.K. with the transferred data.

  4. Ensure that no other software that was using the named directory are active (other than PL5) when you make the switch, just in case.

Firstly I do not have the NIK collection so I would never be able to reproduce that element of your workflow, if the element is actually introducing any problems!

You reported the following

Problems:

  1. New problem just discovered with these two new versions—DXO PL5 on Desktop in Export
    mode, locks up when a JPEG image is made from Tiff image created in NIK Color Efex Pro 4.3, NIK
    Collection Version 5.0.4.2 x64 ver.4.3.0. During Export, the wheel stops spinning and the program
    locks up. I go to Task Manager in win 10 to stop PL5. When I open it again, the JPEG image is
    there. When Jpegs and Tiffs are created in Export from NEF files, PL5 works fine. This might be a
    NIK/PL5 problem. This problem does not occur all the time. Retarting the desktop may eliminate it. (BHT) I cannot comment on this one at all, sorry @sgospodarenko do you fancy getting me a temporary licence for NIK so that I can waste even more of my life trying to reproduce this or was there any response to this part of the error submission by @Photoman43 !

  2. Old problems with Tiff files created in NIK still exist. Metadata is stripped out from the Tiff file. This
    usually means lens used is no longer available. Other data may be missing too. This is very
    aggravating. On screen shots see some Tiff images with Symbol indicating that lens data is available. (BHT) Sorry but not my field of expertise at all!

  3. Synchronization Problems. ( Problems are not always the same in different file folders)
    Virtual and Master files appear. Virtual copies of NEF and Tiff files may appear in the same file
    folder as the Master file when the file folders are opened in DXO-PL5 on my Laptop after having
    been processed on my Desktop. This seems to happen randomly as I can discern no pattern as to
    what makes this happen. I have not done anything to create a Master or Virtual file on the laptop or
    desktop.

I have had this same or similar problem with every version of DXO PL I have used since I first
started using the program with PL3. I thought DXO-PL4.3.1 with the fix for sidecar files addressed
these issues, but it has not. (BHT) Hopefully covered above.

The ‘!’ symbol indicates that a an issue has been detected, I have managed to get a Red ‘!’ and that is really scary. The ‘!’ is persistent because it is effectively carried in the DOP which is essentially a copy of the database entry! So once a ‘!’ has occurred I believe it will “travel” with the image as you move the image and its DOP from system to system (hopefully successfully and without any “unwanted VCs”) as for the reason for the ‘!’ I am afraid I do not know @sgospodarenko.

Hope this helps, at least with some of you problems.

@John7 are you just copying from the USB or across the LAN from one device to another with new directories or old directories but with new images and with DOPs “in tow”. The problem only occurs when a directory is opened in another copy of PL5 (another copy on another machine) and processed when a new DOP will be created, if a DOP then conflicts with a database (the Uuids are not the same) then a VC is the inevitable outcome!

I thought that your workflow might work if PL5 left the Uuid alone when importing into a new DB so I ran a test.

  1. On my Master machine I created a test directory of 4 JPG images and “created” DOPs for them using the ‘Files’/‘Sidecars’/‘Export’ command on my Main machine (F: drive - running PL5.2.1).

  2. I copied the files and the DOPs across to my Test machine (mapped as the V: drive - running PL5.1.4) and opened the files and made a simple but obvious edit to all images.

I had wondered if the DOPs would be imported on T with the same Uuid from the (original) DOP but the result was that a new Uuid is allocated on T and used so the images cannot come back from T to M with the edits in the DOP without the inevitable Virtual copies!

EDIT:-
To complete the story:-

The new directory copied from T(mapped as V: drive) in Beyond Compare to “<>-NEW” and opened in PL5

The original directory renamed (with PL5):-

The “NEW” directory renamed “back” to its original name to complete the switch:-

The original directory can now be deleted at my leisure!

It is that complicated to move data between systems and avoid Virtual Copies (“swing” space is needed because two directories will be in the database and on disk at the same time)!

Unfortunately PL5 does not have functions like copy and past but at least has ‘Rename’ and ‘Remove’!

I don’t understand why the problem. I have been adding camera equipment to my DAM, copied across to the laptop imported to the DAM and checked in PL it was reading the changes (selected it to import the keywords and it did. I than realized I forgot to add a flash so added it on the laptop exported changes to the PC and imported and checked that PL was OK, imported the metadata changes OK no virtual copies or problems?

I also copied over two days of imiges, just copied an messing about and they opend in PL OK with all the keywords, editing in placeevery thing and no vertual copies.
I often edit images when imported onto the PC better and much bigger monitors, export the changes to the laptop never had a problem and bee doing bit now for some 2 years since deep prime didn’t like my laptops age (or I didn’t like the very long time to grind through exporting with it on the laptop). I have never used permanent virtual copies, Ranking, the DAM in PL, Rating and the only problem has been jpg rotation now solved by ignoring PL for it.

I deleted the PL database on the laptop last night, but not on the PC and that happily accepted the changed image’s, dop and xmp files. I can assure you if I had other problems I would be seeking solutions as I do with the jpg rotation problem.

@John7 I don’t understand why you don’t have any problems if you are moving images and dops between PL5 systems that have seen the data before because I have never got that to work. My test above was to see if the Uuid was kept the same (because I once thought I had a situation where it was) but certainly not in my test.

So lets put your sequence into order and see if I can understand your flow

  1. On laptop input images from camera into Photo Supreme (your DAM).

  2. On laptop open in PL5 and read metadata put there by PS (DAM).

  3. Added images from flashdrive (to laptop I believe?).

Up to this point the process is all one way and is the equivalent on me working on Main machine before copying to my Test machine

  1. Copied all all new data (image, xmp. DOP) from laptop to PC for “proper” editing with bigger monitor etc.

This is the same as me working on my Test machine.

  1. Copied the edited directory including the newly updated DOP to the laptop

This is the same as me copying from Test to Main but if I copy to the same directory on Main where the original images still reside then Virtual copies are inevitable iff

  1. I am copying to the same directory and the image names have not changed, i.e. you are copying the original image to the original directory. If you are copying an export from PL5 then that will have a suffix and is a new image!

  2. The original images are still intact in the (laptop) database, i.e. the database has not been deleted before the copy back stage. It is currently not possible to erase a directory from the database but leave it intact on disk (another feature we have asked DxO for, i.e a ‘database image/directory/directories delete’ or ’ expunge’ feature!)

If I

  1. clear the database or
  2. copy to a different directory (possibly because its name was changed after editing on the PC) or
  3. the image names have changed or
  4. I am copying back exported images (with a suffix) or
  5. I am not copying back the (new) DOPs from the PC to the laptop

then no Virtual copy will be created.

I don’t believe that Syncovery has some “magical powers” that Beyond Compare doesn’t have!

If the DOP does not have the same Uuid as the database entry for the same named image in the same directory in the DxPL database then a Virtual Copy will be created. If the DOP is not copied back to the laptop then all will be fine (except that the latest edits will only be available on the PC).

While I am sure that what you do is not creating Virtual Copies if you do exactly what I have done in testing, then VCs are inevitable which means that your process has some “subtle” difference(s)!

The problem I see with your “empirical study” is that it is based on several apps, some of which do not adhere to standards or guidelines.

Heck, when even Adobe doesn’t obey the guidelines they helped to create, what hope has anyone else got?

Entering keywords concatenated with pipe separators might be allowed in the UI - the problem is what happens to those keywords when they get written to the XMP metadata?

Taka look at the tooltip in this screenshot from PL5 that I posted earlier…

How did I arrive at that? I simply copied animal, mammal, bear, animal|mamal|bear from your post and pasted it into the keywords field in Adobe Bridge.

This then gave me an XMP file that contains…

   <dc:subject>
    <rdf:Bag>
     <rdf:li>animal, mammal, bear, animal|mamal|bear</rdf:li>
    </rdf:Bag>
   </dc:subject>
   …
   <lr:hierarchicalSubject>
    <rdf:Bag>
     <rdf:li>animal, mammal, bear, animal|mamal|bear</rdf:li>
    </rdf:Bag>
   </lr:hierarchicalSubject>

All of which is complete nonsense, especially when you see what PL5 comes up with when reading that XMP file. You can see, from the screenshot, that PL5 has created four keywords - the last one being a newly constructed “composite” single keyword animal > mamal > bear. So, for some reason, PL has interpreted your pipe-separated single keyword as a ’ > '-separated single keyword.

What is more, the hierarchy list underneath the keywords field now shows a hierarchy, whose root is a comma separated single keyword animal, mammal, bear, animal with an immediate child of mamal (note the single ‘m’), which has an immediate child of bear

Surely, you have to admit that displaying such a hierarchy is a total nonsense?

Furthermore, if I then go on to simply change the Rating and rewrite the metadata to file in PL5, what I then get in the XMP file is…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>bear</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>animal, mammal, bear, animal|mamal|bear</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

Totally different.

If I then close and reopen PL5, the keywords panel still shows the same nonsense tooltip and hierarchy.

Next test - uncheck the bear item in the hierarchy list in PL5 and then recheck it. What you get is…

Capture d’écran 2022-06-06 à 13.26.53

Now, if I rewrite the metadata to the file, I then get an XMP file that contains…

         <dc:subject>
            <rdf:Bag>
               <rdf:li>animal, mammal, bear, animal</rdf:li>
               <rdf:li>bear</rdf:li>
               <rdf:li>mamal</rdf:li>
            </rdf:Bag>
         </dc:subject>
         …
         <lr:hierarchicalSubject>
            <rdf:Bag>
               <rdf:li>animal, mammal, bear, animal</rdf:li>
               <rdf:li>animal, mammal, bear, animal|mamal</rdf:li>
               <rdf:li>animal, mammal, bear, animal|mamal|bear</rdf:li>
            </rdf:Bag>
         </lr:hierarchicalSubject>

An absolute and totally incomprehensible mess, which Adobe Bridge now reads as…

Capture d’écran 2022-06-06 à 13.34.41

So, it would appear that Adobe Bridge, and possibly other software, allows the input of the non-standardised keywords you have been using - but PL5, understandably, not only cannot make proper sense of it, it then goes on to totally change it to its own version of non-standard metadata, which even Adobe Bridge can’t make sense of.

Guidance? Who needs guidance? Standards? Take your pick :roll_eyes:

For the sake of completeness, the DOP file now contains…

			Keywords = {
				{
					"animal, mammal, bear, animal",
					"mamal",
					"bear",
				},
				{
					"animal, mammal, bear, animal",
				},
				{
					"animal, mammal, bear, animal",
					"mamal",
				},
			},

… and the keywords table in the database contains…

BHAYT, Thank you for your detailed response and recommendations. I will try them. And I will look at # 86 and # 91.

Here are answers to your questions. My responses includes your number.

  1. The images, Jpeg and Tiff, are created using DXO PL5 not Nikon software.

  2. On my Desktop, the Directory name is D: \My Pictures\Download 2022\file folder from laptop. On the laptop, the images came from C:\Users\Joe Smith\Pictures\Saved Pictures\Download 2022\file folder. The name is new on the Desktop.

  3. Things seem to be fine after adding or correcting keywords on the Desktop. I no longer add any new keywords on my laptop in DXO PL. The only ones on the laptop come from the xmp files at the time of download.

  4. Star Ratings in DXO PL on Desktop are fine.

  5. The files created in NIK on the Desktop are saved to the original file folder on the Desktop that holds the Nikon NEF files.

  6. This is where I have problems as the file folders get copied back to the Laptop as described by BHT. Before I copy them from the Desktop to the Laptop, I delete the old file folders from the laptop. I am glad for the explanation from BHT as to why I have the problem of Virtual and Master copies. I am surprised and curious as to why DXO Support could not have provided me with the same response. I do agree that my real solution is to avoid the problem in the first place.

@Photoman43 The first thing I must do is apologise for using BHT instead of BHAYT, I was being “lazy” and saving a little typing, both are derivatives of my names with H being shorter than HAY being shorter than my actual middle name, i.e. BHT = BHAYT = me!

The “problem” is actually now part of a FAQ on the DxO site i.e. https://support.dxo.com/hc/en-us/articles/4733212348573-Why-does-DxO-PhotoLab-automatically-create-a-virtual-copy-of-some-of-my-images- so I would have expected a response from DxO to at least have pointed you at the FAQ (although that depends on when you got a response from DxO).

I will review the rest of your post sometime tomorrow (hopefully) I need to go to the dentist having broken a tooth today (sorry yesterday, the 6th.)!?

If you look at this post I wrote above at Rotation not kept in dop’s why? - #67 by BHAYT you will see me undertaking the very procedure I recommend (slightly different actually but both are about adding the new version, moving the original version to one side, slotting the new version in place (with the original name), and then, when you are sure everything has worked O.K., deleting the original version (as and when it suits you or not!?)

There is obviously a shorter process that could be used namely deleting the original and adding the updated back with the same name as the original but there is a risk that PL5 with simply see this as the current process that is causing the VCs plus I like the “security” of have the old and the new available until I am happy that the swap has been successful.

Doing the operations of renaming and removing within PL5 means that the database can be adjusted directly rather than by PL5 “discovering” that a directory has gone. i.e. it is important to undertake the renaming and removing from within PL5 to avoid any issues and it has worked every time I have done it this way!

Bryan,

I copied two file folders (with DXO PL5 processed images in it) from my Desktop to my Laptop. I renamed the file folders by adding Rev at the end. Before doing this I deleted the two original file folders.

I then opened the file folders in DXO PL5 and discovered that renaming the folder resolved all of my issues !!!. Changes I made on my desktop all appear–new and revised keywords; changes to Metadata; Star ratings and image processing.

My last contact on my issues with DXO Support was in February 2022. I think I started my email to support in Dec 2021 or Jan 2022.

I was not aware of the info at DXO’s website about Virtual copies.

Thanks again.

Joe Smith

@Photoman43 Great! I didn’t know about the FAQs except that DxO had “published” a table (in the Forum) about what was now taken (and not taken - by implication) from the PL5 DOP and before I complained (yet again) about the lack of any formally published information I went looking and found the FAQ I was looking for (better late than never - it should have been part of the PL5 release notes) and also found the one related to your problem which at least states the problem.

However, it offers no “solution” and the response to you should ideally have contained both but at least an explanation for the occurrence @sgospodarenko given that my response in the “Unwanted Virtual Copies” topic was in December 2021!

To be honest I have stated my “dissatisfaction” with the fact that the topic ran for so long with theory after theory after theory after … and DxO never intervened once, it should have been ended by the facts after a couple of posts!!

Regards

from BHT, BHAYT, Bryan Thomas

Bit short as traveling. I am lost after reading faq why I have no problems copying back and fourth. I agree it’s appalling thy couldn’t be bothered to post on it here or it might be an indication of how little they take notice of these customer posts.