DxO PL3 Workflow Question

DxO PhotoLab macOS topics
1

I use a program called Integrity Checker (IC) to assure the long-term stability of my images. IC generates a hash code for each image on ingestion and provides capabilities for verifying the hash on the original and backup copies of each image. Info is given if the image file ever changes, even by as little as a single bit. However, the program operates on every file in a folder, regardless of extension. There is no capability to select only, e.g., .RAW files.

Here are some issues for which I seek advice:

  1. I have a modestly large number of images (about 38,000). I have used several cameras and thus have a variety of file naming schemes. This creates difficulties in cataloging my files, which I am now wanting to do. However, I have processed as significant number of files in PL2 and 3 which has created *.dop files that are in the same folders as the *.raw files. If they remain there, they too will be hashed (that’s OK) but every time a make a change to the image, the top file changes and will be flagged by IC. This is tedious if a large number of files are being worked on.

  2. How is the dop file associated with the raw file? Am I ok if I rename both to the same filename with the appropriate extension?

  3. Can I move the dop file to a separate folder and somehow point to the raw files? This would eliminate the issue of hashing the dop file.

  4. If I cannot do (3) (as I expect), then can I create duplicates of the raw file that can be put in a separate folder with the dop files? I am not sure i understand how the multiple copy feature works–I believe it does what i want, but am not sure how to put the second copy and the dop in the same folder.

Can someone comment on how these features work?

Many thanks

RWH

2

The .dop files contain all the edits to a raw image as well as all the virtual copy information. There is one .dof file for each raw file regardless of the number and type of edits or the number of virtual copies.

You can copy a raw file and its associated .dop file to a different folder or a different computer and you will retain all the edit and virtual copy information. The .dop file must be in the same folder as its associated raw file. Renaming both the raw and .dop files outside of PhotoLab will not give you the results you are looking for. Renaming a file within PhotoLab will allow you to retain all the associated edits.

Did you know that edits are retained in both the database and sidecar .dop files? While I don’t normally recommend it, you can disable the save to .dop and load from .dop options in the General dialog box under Edit/Perferences. If you do, all edits will be retained in the database only. The .dop files serve their main purpose when moving an image to a different folder outside of PhotoLab, when moving images to a different computer, and as a backup if the database becomes corrupted, or so large that you want to delete it and create a new database. Of course, periodically creating backups of the database ia also a good idea.

Mark

image
image1769×995 417 KB

1 Like
3

But without the dop files you will loose all your edits, isn’t it?

George

4

George - correct, you will loose it.

1 Like
5

Robert,
in regards to renaming, moving etc… I use Photo Supreme as my DAM software. When I change the name of a file withinin Photo Supreme, all sidecar files (.dop, .xmp etc…) will be renamed automatically. The same goes for moving files around to another folder, deleting a file etc… As long as I do that within Photo Supreme all sidecars will be moved etc… automatically.

I would assume other DAM software does the same - but I do not know.

Sigi

6

XnViewMP too when declaring “dop” as a associate file extension.

Pascal

2 Likes
7

I do not have to associate any file extension within PSU,

8

Where/how does one declare this relationship to XnViewMP, Pascal ?

John

1 Like
9

John
I thought about you to ask this question :smiley:

Parameter / File list / companion files
declare a new line:
Main extension: {raw} Companion: {ext} .dop

Have fun
Pascal

3 Likes
10

Yes. That’s why I said, "The .dop files serve their main purpose when moving an image to a different folder outside of PhotoLab, when moving images to a different computer, and as a backup if the database becomes corrupted, or so large that you want to delete it and create a new database. "

Mark

2 Likes
11

If you use the DAM side of pl you can’t afford to loose the data base.

12

Correct. Unfortunately, the new keyword feature only writes entries to the database, not the .dop sidecars.

Mark

1 Like
13

That’s a huge oversight. Robert, the short answer is you don’t want to turn off the .dop files. It’s living life on the edge for no good reason. It would make sense to use copy software which hashmarks the images before and after the move. The long time integrity monitoring is an interesting proposition: most of this kind of software can be run command-line.

I’d look to find a way to let it loose on the images only by either a static configuration file or running it via command-line. If the current software won’t do this, there are other command line tools which will do so.

14

As others have mentioned, a ‘real’ DAM should handle ‘buddy’ files (including .dop files) transparently for things like moving or renaming. I use IMatch https://www.photools.com/, which has a large number of features for managing image collections. I would also strongly recommend keeping your .dop files instead of relying only on the PL database.

15

Welcome back Alec. The last time I saw a post from you must have been at least a couple of months ago. I agree that not writing keywords to the sidecar files is a huge oversight which I hope is corrected soon.

Mark

1 Like
16

Haha … I was being lazy, Pascal !

Thanks - - John

1 Like
17

That’s a definite +1 from me as well.

I realise that adding keywords is so that the files to which they pertain can be found quicker in a SQL database than by trolling though all the directories on your disk but…

… at the moment, everything is kept in the same database with the unfortunate consequence that, should the database corrupt, everything is lost - including projects and keywords.

In theory, the database should never corrupt but that doesn’t account for the app crashing part way through a write, or a power cut switching off the computer unexpectedly.

Were it my app, I would have, at least, three databases: one for the editing data, one for projects and one for keywords.

However, because of the problem of database fragility, I can see a lot of sense in writing, not only editing data but, also projects and keywords into the .dop files; with the ability to rebuild the database whenever a directory is re-indexed, or on a low priority thread in the background whilst the app is running.

As far as I can determine, a lot of people choose to use .dop files specifically because they don’t feel they can totally trust the database. From real world experience as a developer, I would always advise anyone to create regular backups of any SQL database, depending on the volume of work done, as often as once a day. But remembering to do that can be onerous - far easier to keep everything in .dop files, only relying on the database for speed of access when searching for keywords.

The big question - apart from indexing keywords, do we really need the database at all?

2 Likes
18

Hi Joanna - - I’m one of those people.

I don’t depend on the database because I don’t need to: I have zero interest in the DAM features of PL, so I’m very happy to have PL generate (and use) sidecar/.dop files associated with each and every one of my RAW source files.

I regularly delete the database file(s) - in order to speed-up and simplify the PL start-up process - with full confidence that PL will rebuild the database from the content of relevant sidecar/.dop files, on an as-required basis.

As you can see, from my perspective the answer is “no” … Tho, it’s probably used by PL for efficiency purposes (as in, it’s faster to read from a SQL table versus parsing a text file) - and it’s not doing any harm.

John M

3 Likes
19

Its not unknown for support to what the data base deleted, as its an area that clearly can cause problems. I agree I see no point to the data base with out repair tools built in and ways of checking it. When I export my DAM data base it veryfys it I don’t think PL has anything like that.

20

Hence the idea of separating out the (very limited and inadequate) DAM into a separate module, allowing it to be integrated back as a module in the same way that FilmPack and ViewPoint are.

4 Likes