Keyword transfer between DxO versions

DxO PhotoLab
1

I am using PL6 (I did not see any features of PL7 to make it worthwhile upgrading) and use the keyword function at a fairly simple level (species and location for bird photography).

I recently decided to check out PL8 and downloaded the trial version. When processing images I noted that my list of keywords had not been loaded. After looking through the menus I found that I could load my database from PL6 through the Preferences, which loaded the keywords.

What I didn’t realise (but found out the hard way) was that PL8 modifies the PL6 database in a way that PL6 does not recognise. I understand this is just how PL works, and that later versions of the database are not read by earlier versions. When I went back to PL6 I got a message saying that it didn’t recognise the database, and the program was going to back it up and create a new one. The new database did not include any keywords. To recover my keywords I had to restore an older backup in PL6 (inconvenient but not a catastrophe).

As far as I can recall I have never before had a problem with new versions of PL loading my existing keywords (I have used every version from 1-6). For example when upgrading from v5 to v6 I don’t recall going through any particular steps to get keywords visible (although I accept I might just be misremembering). Nor do I recall having this issue with keywords when trialling other versions of PL before upgrading. I don’t recall every having to manually load a database from a previous version to be able to use my keywords; it’s not something I have every given any thought to.

My Preferences are out-of-the box - I have never messed around with them. The only box checked on the metadata tab is ‘Whole heirarchy of selected keywords’. The buttons under ‘Synchronisation’ are always unchecked.

Is there a simple way to easily move keywords to a new version without having to load (and mess up) an older database? Does the fact that I skipped PL7 make a difference? I feel like I am missing something obvious.

Thanks
Simon

2

Yes. Copy the old database and then import that instead of an active one.

Although, I agree that importing into a new version shouldn’t trash the old one. Perhaps a support request or bug report might be in order?

3

Thanks, that’s logical, but why doesn’t PL8 just pick up the keywords from the previous version? I would have thought that as you move to a later version, things like keywords should be automatically transferred. I thought this is how it had happened in the past, but perhaps I am mistaken, although as I said I can’t remember ever having to manually mess around with databases to get keywords to be picked up by version upgrades.

4

That’s a valid question, given your past experience and common sense. If I were you, I’d consider reporting it.

5

I have had problems when upgrading from PL5 to PL6, with a mess in DB. I had to ask the support and allow them to access my PC remotely (you have to download Team Viewer last version, they will give you a link). It solved the problem in 15 minutes.
Now, before any upgrade, I copy the last DB and rename it in a specific directory in order to be able to recover my self if necessary.

6

Moreover, you should first create a test directory for the new version, else you risk getting multiple VC.

7

If you have your pictures organized in a structure where all your picture folders are stored in “a top folder” and you delete your present databae file (or better moves it to a backup folder first), it then is very easy to build a new database including a fresh keywordlist build by Photolab automatically.

The only thing you have to do is finding that “top folder” using PictureLibrary that holds all your picture folders and point to that folder before starting the indexing process with PhotoLibrary. Photolab will then start to index all the metadata that is stored in either the XMP-sidecar files that is stored beside every RAW-file or is stored inside the XMP-compatible fileformats (JPEG, TIFF and DNG) XMP- headers.

The only problem with doing this is that you will loose the eventual “Projects” you might have created before and you will also loose eventual “External Search”-history because there is no easy way to migrate these data if you are not familjar with database management tools like SQL.

This way to do this is really the only vway to migrate from any other converter software and this is a problem if you have used say the keyword-vocabulary from Lightroom or any other “controlled/standardized vocabulary”. You see otherwise you will just get the words used and stored in your files in the newly indexed keywordlist of Photolab. I have enlightened DXO ago about the necessity of adding a function in PhotoLibrary that let us import and Export the keywordlists. Capture One is built like that and so is PhotoMechanic.

I once had a computer crash and needed to sync my keywords between Photolab and PhotoMechanic and I had to use Capture One to fix that problem by indexing all the XMP-picture files and then making a reindex in Photolab too.

When I once tested to use a Lightroom vocabular in PhotoMechanic it was just to import it and start working. That ought to be the case even in Photolab/PhotoLibrary. As it is now theere is no migration tools in Photolibrary which locks the users to Photolab when it comes to XMP-metadata migration.

To be able to migrate is essential for me so that is one of several reasons why my XMP-master isn’t PhotoLibrary but PhotoMechanic. The other more important reasons are scalability and being able to handle more than one database at the time when searching my pictures and the maybe most important is the much better productivity PhotoMechanic offers when maintaining XMP-metadata.

8

@SimPel
So far, I’ve not seen DPL8 messing up databases or not importing keywords…when it was installed the very first time. The PL8 database was put in a separate folder and content was imported from a previous database. Re-installing PhotoLab is different though and in such cases, I usually got up and running by restoring, into DPL8, the database from the previous version, e.g. DPL7 or DPL6.

All of the above is on Mac and I suppose you’re using Windows or have an idividual issue that is best addressed with a support ticket as others have already proposed.

Nevertheless, it pays to back up the current configuration before installing a new major version of DPL (or any other software)

9

If it is about getting back just the keywords and the keywordlist matching what is used on the pictures into the database a reindexing is the absolutely simplest way to do it - and there is really no other way to do it in Photolab if there should be some sort of a database-compatibility issue between version 6 and version 8.

You are always taking a risk when you skip to upgrade in a consequitive way like from 6 to 7 and 7 to 8. Sooner or later a strategy like that will probably inflict some sort of an extra compatibility cost. If the database schema has been altered between version 6 and 8 you might not be able to open a version 6 database in version 8.

So if this is what actually has happened here (which I have no info about - this is just a hypotetical discussion) there is no other way really than to reindex using the XMP-metadata in the files. In fact, the database ought to be seen as the single point of failure it really is and if you are in version compatibility unsync, it will not help either with a restore of a version 6 database if version 8 is not supporting the schema of that database.

That is why the distributed XMP-metadata in your files is us such a blessing and rock solid metadata backup! If one or a bunch of your metadata-files are missing or corrupt you will still be able to restore the XMP from all the rest of these files and that is aa very big difference from the other case when you sit there with the corrupt file that happens to be your PictureLibrary or any other monolithic archive-file like the one in for example Lightroom.

The only thing you need to do is to always organize your RAW-picture folders in a two level hierarchy so it is easy to reindex if it becomes necessary. All picture folders ought to be placed under a topfolder and then it is just to point to the top folder when starting the reindexing in Photolab.

2 Likes
10

No matter what you call Lr’s database, Adobe managed to keep it up and running on my Macs since Lr version 1. DxO, on the other hand, has not yet managed to improve DPL database robustness. If this were the case, we’d not see threads like this one.

Anyways and as you write, the sidecar files are a blessing in cases of database issues. It’s good to keep the .dop files as a “db backup” and the .xmp files for metadata interchange with other apps.

PhotoLab sidecars (.dop) have qualities that go beyond those of Adobe’s .xmp files. One of the .dop bonuses is that they also contain the necessary info for virtual copies, something that Lr doesn’t provide.

3 Likes
11

Thanks for the discussion.

I seem to have fixed the problem (as far as I can tell) by doing a clean reinstallation of PL8. I uninstalled PL8, downloaded a fresh copy, and reinstalled. (Windows 11 PC)

The new installation immediately defaulted to the PL6 database, which was the one the previous version of PL8 had been loading. Clearly uninstalling PL seems to leave some data behind in C:/users in case you want to reinstall it at a later date, including where to find the relevant database.

I deleted the previous PL8 database which had been put in “C:\Users\Simon\AppData\Roaming\DxO\DxO PhotoLab 8” when I first installed PL8, and set preferences to look at this blank directory. A new database version was created whe PL8 was closed and restarted which included data such as keywords from the previous version of PL, and it appears to be functioning correctly. I presume this is one way of doing the re-indexing process described by Stenis. The first/original version of the database was just a few Mb whereas the current version is over 450Mb and similar in size to the PL6 database - which suggests the PL8 database had not been properly established initially or had been corrupted.

This would suggest that my initial problem was caused by a faulty installation of PL8 trial version.

I have now discovered a new issue, which is that all pictures modified in a previous version of PL are loaded with a virtual copy containing the edits from the previous version. I see there are other threads about this which I will need to investigate. Another new behaviour from PL8 which I have not observed before when going to a new version of PL.

Thanks
Simon

1 Like
12

The VC are created because some of the new functionalities of PL8 aren’t in PL6. So, you will be able to open these pictures with PL6.

13

Congratulations, lucky you but don´t push your luck.

I have had a couple of crashes (and one in the beginning when I lost it all with that corrupt database) and at least what I recall Adobe has always thought that they are the center of RAW-converter universe, so to activate metadata sidecar files at least WAS AN ACTIVE ACTION YOU HAD TO DO before Lightroom created any XMP-files beside the RAW-files or saved that data to XMP-compatible files like TIFF, JPEG and DNG. Adobe have always seen the Lightroom database as the center of their metadata universe and not the XMP-files and that I think is a very big mistake because XMP-sidecars I think always ought to be saved in parallell with the database updates. The database is a single point of failure and XMP is not. So in this respect I love Photolab and I also love that Photolab always is working right on the the picture-files in the file system without any importinterface like in Lightroom or Capture One (if you don´t use the Session-mode in C1 - which I prefer of the same reason.)

I also think the DOP-files have some underrated qualities in this case but there is a problem though because I have seen problem with Photolab’s ability to keep all these sources in sync and I also think it can be a problem with the interoperability between Photolab and other applications if these do not support the integrity of the “holy trinity” of Photolab RAW-files like the RAW-file + the DOP-file + the XMP-file. PhotoMechanic handles this correct BUT it is a support you first have to configure.

1 Like
14

That looks like a nice thoghtful action of Photolabs developers but why would you want to mess with a parallel version 6 Photolab when you have upgraded to version 8 but isn´t the though more about giving you a compatibility option that let you export the version 6 postprocess pictures in parallell with a version made fully out with version 8.

May I ask you if the same corrections you find in the virtual copy also is to be found in the “Master” (M)? … or is these masters empty on edit metadata?

15

I’m not sure I understand your question. However, the VC has all the metadata from the PL6 edits. For example the keywords for that picture are listed, along with the crop size. Edits are applied correctly when the picture is opened in PL8.

The M version, on the other hand, has only the edits applied by the PL8 preset (until I do further editing in PL8). It is opening the unedited raw file and applying the preset (which in this case is the default DxO Natural).

I agree that I am unlikely to go back to PL6 if I purchase PL8. It is only while I am using a trial version of PL8 that I am interested in not mucking up the PL6 version.

Perhaps DxO could make a user-select option whether to open files edited in earlier versions as a VC. For example, a button in preferences I could check if I wanted to keep the PL6 version of the DOP file, or convert the DOP file to a PL8 compatible version.

To follow up on Stenis’ comment about the LR catalog, one of the things that drew me to DxO Photolab in the first place was that it kept the basic Windows file structure underneath the PhotoLibrary, and files do not have to be imported.

16

When a new version is issued, actually, you (may) find bugs. So comparing with the older version is usually necessary. In that case it’s OK to create a new VC.
The big problem is that, sometimes, as the data base is not properly managed, just when you’re browsing, the new version “discovers” images and then creates new VCs. Creating a new VC to allow you to use an older version is fine, as long as the SW does so only when you begin to modify a photo.

17

The feature missing is the ability to sort VCs by PL version number.

18

DxO sales argument: With PhotoLab, you don’t need to import your images.
It’s not a lie, but it’s not quite true either: The user does not have to do anything to import images (explicit import), PhotoLab is doing this behind you back (implicit import), whether you want it or not. PhotoLab is like a vacuum cleaner: it sucks up dust and your kid’s smaller Lego pieces.

Import? It’s what every library does: Adding assets by putting metadata into a catalogue or database. The assets themselves (books, photo files) stay where they are, in our case in a Windows (or macOS) file structure. Apple Fotos, on the other hand, copies the files into the photolibrary, renames the files and puts original names into its own metadata pot…unless you set Apple Fotos to NOT copy the files to its library.

19

That is a little strange that the VC in your case is the picture holding the metadata. Usually, it is the other way around, which is a problem in itself.

In my workflow I use to add metadata before I start to add any Virtual Copies because I then don´t have to do that manually. It has happened that I totally have missed to add the metadata to these VC-pictures of that reason.

In fact I think it would be a nice feature to have that the metadata at least as an option should be automatically mirrored to the VC if one add metadata to the master when both of them initially lacked metadata. Or is there a reson for not doing it, that I might have missed??

20

Treating each VC as a separate file has its merits, specially if you want to add different metadata to different VCs. You might e.g. add different captions to different crops, allowing to emphasise different parts of an image through virtual copies.

1 Like