Lightroom classic has the ability to have multiple catalogs which is great for keeping the databases down at a manageable size. I used to have one Catalog per year and kept it with the photos.
Photo mechanic Plus can do the same thing with the addition of using multiple databases at the same time.
I would suggest you find a third party solution for photo management and simply rely on PL sidecar files for editing. Works perfectly for me with Photomechanic Plus.
PL’s database is woefully inadequate and specially since you only have one and it does not have any management/maintenance features. It will eventually hobble you when you need to break up your photos into more manageable groups for offline storage, archiving etc. or need to reindex everything again because it git corrupted or something.
@KeithRJ You have me puzzled, not difficult I know but …
With respect to DxPL’s database management capabilities they are largely absent and its file management is woeful.
You can drag images from one place to another (but not directories) but that is difficult if you have a large number of images to drag over many directories until the you finally locate the target but DXPL doesn’t scroll the images list you are traversing so you may never find the target, i.e. copy and paste should be present in the product and the directory list should scroll and you should be able to drag entire directories, but I think that introduces a more complicated database fix, actually it might be easier!?
However, you can have as many databases as you like, at least on Windows, what is this for
You can back a database up and the next ‘Restore’ can be any (DxPL) database you care to choose, albeit only one at a time and the product will need a restart. So if you want to keep the entries by year nothing could be simpler!
You are a windows user so you can even open the yearly database in situ!
DxPL deserves much criticism but not all is justified.
@unchdxoly Please beware having all three files present, the -shm and -wal indicate that the database is either still in use or the process using it last failed to shut it down properly.
The former means that if the deletion is successful then the application is likely to terminate unexpectedly and the latter doesn’t matter if you are about to delete the database completely!
In fact I am not sure what having a -shm and -wal will do when DxPL opens if you have overwritten just the DB file!?
Quite alright, but we can do ourselves a favour by using a more reliable manager than DPL. Photo Mechanic would probably be my choice if I had to (or wanted to) drop Adobe products for good.
The main thing I want to convey to all who want to reorganise their photo collection is to think about folder structures BEFORE starting to move things around. Finding a balance between the number of folders vs. the number of files per folder can be beneficial. Imagine having to fence in a patch of land of 100 square meters and a square patch needs less fencing material than a long, narrow strip.
Just for the fun of it, I created one more volume into which I made Lightroom (with a new catalog) copy all fotos into a flat structure. Copying was done in about 10 minutes and the volume contained about 45k objects for 33k image files and sidecars, movies etc. Created a few smart collections and things worked as expected, relatively smoothly, but things weren’t really snappy. Helper and preview files next to the catalog took much space on the volume too. I knew it wasn’t advisable, but Lightroom coped with the situation fairly well.
I then opened DPL8 and pointed it to the new archive. And while CPU load got up to about 400% after a while, activity monitor reported DPL to be unresponsive and I force-quit it. Tried a few times…but DPL did not act nicely so I terminated it and will remove the volume again.
Hi
I started with DxO OpticsPro about 10 years ago. I have always kept my files and folders and the name of my photos very well organized yet the structure of my data evolved over the years. I have naming codes too and one of these codes turned out to be rather impractical so I changed it which implied renaming about half of my collection (about 15,000 shots).
I didn’t see any impact in DPL.
Moreover, since my shots are organized by themes (and not by dates), when I make new shots pertaining to an already existing theme I drag the corresponding folder into the “To do” folder where I sort and edit new shots. When done I drag it back to its place in the collection. I never had an issue.
I wish I could do that in DPL rather than in the Finder. When DxO will implement a full fledge DAM?
BTW I have no clue about the database. What reference document do you advise?
Nick
PhotoLab’s database implements the catalog of files, folders, edits, metadata, keywords etc. Moving or renaming files and folders will eventually bring up the following:
PhotoLab remembers a folder with photos, but as they have been moved/renamed/deleted, the “images” show a question mark instead of a preview. These lost files cannot be deleted. When I try this on my Mac, I get an answer like “PhotoLab cannot delete this image because it is missing”.
PhotoLab 8.3 on Mac allows the following “moving” actions:
Find a missing folder (but not a missing image)
Move image(s) from one folder to another - if the target folder is visible in PL’s browser.
Rename a folder
Add a folder
Move a folder to the trash
Basically, these (new) functions can be used to rebuild a folder structure. And these actions should keep the database/catalog intact. This needs further investigation though.
WARNING:
If a folder is created or renamed, it can be handled in the “device” or “favourite” trees of DPL’s browser. Depending on what I do, I get orphaned items in “favourites” and/or folders in “devices” both of which cannot be deleted. I was able to remove these items in the browser by re-indexing the parent folder(s) and restarting DPL. As of now, I’d advise against relying on those features without making sure to have a working backup of the photo archive. The feature is highly asynchronous, which leads to strange views and the aforementioned “cannotremove” issue.
Hi platypus.
Thanks for your quick response.
I never had question marks.
I am so used to manage my collection in the Finder I didn’t notice that in DPL you can now do stuff to folders. Yet one operation is still missing: move a folder.
So if I move a folder in the Finder I should re-index it, right?
Ditto if I rename shots? For that operation, the DPL feature is pathetically inefficient. Since, most of the time I do it in batch, I have always used Automator, the best ute I’ve ever used. Practically all my pics have one virtual copy on top of the master, sometimes more. Strangely enough with DPL, if you select whether the master or a virtual copy and choose Rename, it renames just the selected item and not the others. I you select all of them it opens an unusable dialog box. It’s as if you had selected different shots.
Is there any risk with indexing folders?
This is not available (yet?) As of now, reorganising a photo archive in PhotoLab means, that target folders must be present before they can be populated. It’s probably easier to do in the finder and index the new structure afterwards. ***
PhotoLab will automatically index the folder and its content as soon as you select the folder in DPL’s PhotoLibrary browser. There is no need to do it explicitly.
PhotoLab understands VCs as individual images and selecting one copy means that you’ll deal with one copy only. Selecting several images, no matter if they are a master or a VC means that you’ll deal with several images. You can learn to use the unusable renaming dialog and make it do as you wish.
Apart from the rather philosophical answer “there is risk in everything”, my answer is “yes and no”. No, it won’t delete any image files and yes, it will add information to the catalog (database) like a vacuum cleaner. It just adds to the mess, if there is one…but I’ve seen changes in how PhotoLab deals with things and maybe, in a near or far future, PhotoLab will be able to provide means to “fix” the mess with something more subtle that “just delete the database”.
Note*** Information about virtual copies are stored in a single .dop file per master and copies. Lightroom stores nothing about VCs in .xmp sidecars. Test moving before trusting that all the sidecars you need toddle along with the image files.
Is there any hope DxO will implement some day a fully fledge DAM with all the EXIF, IPTC, keywords, etc., data?
I have always been using Adobe Bridge when I just need to review my collection without needing to do any editing. It’s well integrated with MacOS: you can drag and drop, drag and duplicate, copy and paste items from Adobe to the Finder or Automator and vice versa.
The issue with Bridge is that it doesn’t display pics as edited in DPL and that its user interface consistently deteriorated over the years.
So I can continue with my procedures as usual.
To me when I do export they are different images (although I never export the master) but it’s one shot so they must have the same name.
After I copy new shots from my SD card my first move is to name them which includes:
I give to each a unique ID. So in my ~15,000 pics collection there are not two files with the same ID. It’s very handy.
Shots with the same subject are given the same name (which can be very long).
I makes it easy to identify what it is.
This job is made very easy and fast by Automator. Therefore the combo unique ID + common names makes it easy to browse and sort files without any conflict. Searches are very easy too.
I may need to makes changes to names for different reasons:
I made an error.
I got new info about the subject that I initially didn’t have.
I changed my naming conventions (it happened several times).
they need to be more conventional for display purposes.
So renaming files is a common practice. Only Automator can make it a breeze.
Renaming a file in Finder is no big thing as macOS keeps track of things with Spotlight. Also, Mac’s have used IDs before Mac OS X and the visible file name is a label for easier handling by humans.
Renaming a file in Finder can cause issues with all apps that work with filenames, but don’t track them, be it with Spotlight or any other way. PhotoLab has, so far, not been good at tracking files (put mildly) and whether it will eventually do a better job is hard to tell. Many of us would be happier if it did, but it looks like DxO has other priorities.
As far as I understand DxO, they have always worked to deliver the best possible image quality by correcting flaws caused by lens design compromise, technological possibilities etc. Managing assets doesn’t make images look better, but some functionality was requested by users and DxO implemented some of these requests.
Given the state of affairs of DPL in this area and imo, PhotoLab is best used as an add-on for the development of RAWs and within that scope, DPL’s database can be deleted from time to time.
At one point with OpticsPro (in the 2017ish) renaming files in the Finder had a curious consequence: the new name was displayed in the title bar of the window but the film strip would still display the old name. Exported pics would bear the new name so it was not an issue. To try to solve the glitch I opened the .dop sidecar, which is a plain text file, and, although the file itself had the new name, inside the document there was the old name only. I made a test: I did a find and replace inside the file. Once the pic displayed in OpticsPro nothing had changed. So I reopened the .dop file and the name had reverted to the old one.
This doesn’t happen anymore with PhotoLab.
