Implementation:
One possible implementation is to have a “Create Local Database” menu option that creates a new database and cache inside the current working directory, ideally in a subdirectory. DxO PhotoLab would check for this directory first and use it as the database and cache for all photos in that directory.
Problem Solved:
The working directory could be picked up and moved anywhere and edited from any computer.
Related Requests:
There is another feature request to support Capture One sessions (perhaps for different reasons) that would solve the same problem. I felt this was a simpler and different enough approach to warrant a new request. I also saw several proposals for editing photos on multiple computers but those seemed manual and difficult to manage correctly.
I’m OK forfeiting global search capabilities for images that use a “local database”. I believe the same is true in Capture One. I typically create one session per event, send the exports to my DAM, and archive the session. If I want to edit the photos again, I can just grab the session and make the edits wherever I want.
No problem at all if you use a sensible folder structure, e.g. something like this:
We can devise other structures, but possibilities to build a
multidimensional structure in two dimensions are limited.
It is good practice to create unique names for folders
on all levels.
Structure by date: Year > Month/Week/Day > Occasion
e.g. Photos > 2001 > 2001-10 > 2001-10-Illinois
Structure by location and date: Location > Year > Location Detail
e.g. Photos > USA > 2001 > 2001-10-Illinois
Structure by customer: Customer > Job-ID > Details
e.g. Photos > NatGeo > NG2358 > 2021-Illinois-Great Lakes
Good point. In Capture One, there is an import step so you have a chance to create a session before Capture One catalogs the photos. I think you’re saying “master” PhotoLab database will already know about these photos when you create the “local” database so some cleanup is required. Perhaps the “Create Local Database” function could simply move (not copy) the data from the “master” to the “local” database? There’s probably no need to worry about the cache. The “master” cache entries will eventually expire/evict and the “local” cache will be built when you work with the files.
The main issue with today’s implementation is that the database easily collects info that will be rendered obsolete if e.g. items are moved outside of DPL, when it’s not running.
On MAC: Starting with PhotoLab version 2, DPL will instantly (and afaik correctly) update the database when images are moved with the finder. Haven’t tested with renaming or folder renaming though.
Hi Joanna,
I wanted to spend more time crawling through the forum and user manual before coming back to this. Unfortunately, it’s still not clear to me what happens in the following scenario:
I edit a file which produces a *.dop file in the same directory.
I move the directory (not via PhotoLab) to an SSD or other location.
I move the directory back to my Mac for additional processing.
In step 3, will PhotoLab:
Read settings from the *.dop file and create a second entry in the database?
Read settings from the *.dop file and update the original entry in the database?
Read settings from the original entry in the database unless I import the *.dop?
I think the answer is #2 if I am on a Mac (and perhaps if I don’t rename the enclosing folder):
Secondary is what happens to any cached versions of the image.
The more I read, I think I prefer (in order):
An option to disable the PhotoLab database (suggested elsewhere in the forum).
An option to use the database only for specified “watch” directories (similar to ON1?).
I work this way, effectively, by deleting the database before each PL session (I achieve this via a “wrapper” that performs the deletion - including thumbnails and cache - and then invokes PL) … so that I rely only on the sidecars.
This works for me because I operate on only a small’ish batch of images at a time, in a Work-in-progress folder. As I complete each batch I move it off to an archive location, and start with the next batch.
Thanks @John-M. That is similar to my workflow (which I am trying to replicate in PL):
cull raw files with FRV
import picks into C1 session
C1 edits, C1 exports
import C1 exports into DAM
archive session
The more I think about this, I really like Nikon NX Studio’s approach. AFAICT, NX Studio allows you to specify a cache location, but it does not maintain a database (or catalog, if you prefer). There is an option to save all edit information to the raw file itself (not really a 3rd party option) or to sidecar files. If you specify sidecar files, nothing happens until you label or edit a file. Once you begin working on a file, it creates a subdirectory called NKSC_PARAM. The XMP and edit information is saved to a *.nksc sidecar in this directory. All files in a directory save their XMP and edit information into the same NKSC_PARAM subdirectory. This keeps all information with the raw files while keeping the original directory tidy (as opposed to having a *.xmp and *.dop file for every processed raw file).
What do you all think about the Nikon NX Studio database-less approach to recording labels and edits?
Thank you. As a DxO newbie, I appreciate your guidance. I’m concerned that there may be scenarios where the database takes precedence over the local *.dop sidecar files and the database information is stale. I agree with your statement if such a scenario can never exist. Hopefully, you or someone else can tell me that is the case. That is the ultimate goal of this feature request. If it is not the case, I would like an option to disable the database or an option to localize the database (similar to a C1 session). It would be nice if the directories were tidy (similar to C1 sessions or Nikon NX Studio), but that is not a requirement.