Allow users to configure PhotoLab to run without using the database.
That is, that all image edits and metadata should be written only to sidecar files if this option is selected.
Hi Mike, This is how I’m currently using PL.
I created a “wrapper” that deletes the database (and the thumbnail cache) each time before PL is invoked … However, there are some caveats to be aware of …
This approach works for me because I use PL only within a Work-in-Progress folder, with a small’ish batch (~25 max) of RAW files at a time. As I complete each batch I move the results (RAW + sidecar/.dop + Exported-RGB) into my storage/catalogue structure - - and then I repeat with the next batch.
If, however, someone is using PL in an incremental manner, within a folder containing 100s (or 1000s !!) of RAW images then one of the key advantages of the database (and the image cache) is that it enables faster start-up time for PL - as it does not need to work its way thru all those sidecar/.dop files just to render thumbnails in order to get PL into a “ready to go” state.
I reckon the reason that PL does not provide this option is exactly because of this efficiency benefit.
John M
4 Likes
By deleting the database you are also deleting any keywords, and once the Windows 10 version has the saving of history entries across sessions implemented that will be deleted as well. Of course you may not care about either feature.
Mark.
1 Like
Nobody says that everything has to be in the same database. You could have one for image data, one for projects, one for history and one for keywords
4 Likes
I’m also deleting the database quite often to avoid the problems with file modifications outside of Photolab (images processed on another PC and then written back).
For me, it would be o.k. if Photolab would provide better control about priorities. This means, it may keep a database but provide settings to always override it by use external changes instead of creating virtual copies.
1 Like
Yes, this would be the ideal solution - - - We could then pick&choose particular database-specific options.
John M
2 Likes
I voted, but for me it’s not whether PL has a database nor how many databases. It’s about how the product works.
I would suggest the better request would be “allow shared folders”. Personally, I had previously wanted the option to import and export libraries as I had a desktop and laptop computer and the idea was to create a small travel library on the laptop which could be worked on on the road and then merged back into the desktop one later. Lightroom allows for exactly this kind of usage.
The reason I don’t want this feature any more (for now) is I no longer have more than one computer.
2 Likes
Hi,
Having one database for each data category means no database at all. In this case, you might as well use a spreadsheet for each data category. The main interest of a relational database is to use the relationships between all the various data available to a program in order to provide features that could not be implemented otherwise. A unique relational database also allows to avoid data duplication (this will necessarily occur if you use “specialized” databases) which is a well-known source of bugs.
Just forget this idea 
. No reasonable developer would go this way.
2 Likes
I am well aware of the perceived benefits of one RDBMS but, in this case, you have a user base, some of whom don’t even want the “main” database for storing adjustments, preferring to use DOP files. So, now, we have two “sources of truth” and they are not even related.
Projects are not something that everybody uses but, as recounted to me by a friend who uses DOP files instead of the database, when they did use them, it only took a slight corruption of the main database to wipe out all their projects. Unlike the editing data, which can be reconstructed from DOP files, when projects, keywords or history points are corrupted, they are lost forever.
Fine - keep everything in one database but, at least, provide some mechanism, let’s say an on-disk file, from which the database can be reconstructed. As it is, there are already calls for keywords to be, not just read from, but managed in XMP sidecars - surely, it would make sense to use that as a “backup”, not just for keywords but also projects and history.
Obviously those who call for the removal of the database do not use projects, keywords or the history.
I’m a developer, and I’m more than reasonable 
, I have learnt to be pragmatic and know when to “break the rules” of normalisation - after all, isn’t that what DOP files do by providing an external source of truth?
1 Like
This raises another question about what a reasonable user should do. Nowadays, it’s easy to setup a daily incremental backup of this kind of data. If a database corruption occurs, I can restore it to the state it was in the day before or even to any state it was at any date during the last “n” days. If the user doesn’t use keywords, projects or history, the corresponding tables remain empty. and the database just contains image related data. There is no additional work for the user, just a free backup.
Separating information in various files instead of collecting them in a central place can lead to very complicated situations. Just look at how Photoshop is storing the program settings. A real nightmare. Nobody really knows how to backup and restore them. Third-party utilities have been written just to manage this.
I’m not against sidecar files. On the contrary. They are rather practical when working on an image at a different location. For example, in my photo club, members can come to our digital lab with a RAW file about which they need advice. We can work in DPL on that image and the member then goes back home with a DOP file that he can synchronize with his database. We do the same with Lightroom.
Well, I don’t see the benefit of eliminating the database. Disk space is not an issue, everything is done transparently and the database and the sidecar files can be used as a mutual backup if automatic synchronization is disabled. Sidecar files and database are not mutually exclusive. Using both gives the maximum flexibility. So, I don’t see any good reason for disabling the database. Should it be split in multiple “specialized” databases ? Here again, I don’t see the benefit. But I see drawbacks : loss of a transparent backup, loss of any metadata based search, loss of some mechanisms like the LR/DPL roundtrip ( I guess that the necessary data are stored in the database)…
Also, I suspect that a “no-db” version of DPL would quickly lead to another kind of request : please let me store my edit settings in the RAW file itself (like Canon’s DPP). Not a very good idea. There is a well-known RAW processing software on the market that doesn’t use a database, only sidecar files : Silkypix Developer Studio. Although it does a rather good job at handling RAW files, it doesn’t offer a very exciting user experience, to say the least.
I would if I could save them outside of the database (or in a database that inly contains the projects).
Because for the rest I do not rely on the database and it is a disposable thing at the moment.
Hmm, “obviously”?
I heavily use keywords and other “descriptive” metadata like location information before sending images to agencies, and I store it where it belongs: In the XMP section of a Jpeg, or in a XMP sidecar for a raw file (I’m not using DNG). Some stuff also copied to Exif (or legacy IPTC IIM when required by an agency) according to MWG suggestions.
I use Photolab projects on a temporary basis to collect images to be processed together by Photolab. Besides this, I use a much more powerful DAM (IMatch), but even there, I could reconstruct most information from the XMP data in the files.
Photolab has issues if files are processed externally. It’s behavior about external edits is not well documented (e.g. network shares and local drives are handled differently but I didn’t find documentation about it). And the data flow is not completely under control of the user. Lightroom and IMatch provide much better control in this regard.
Before someone makes quick suggestions, be warned: It is a pretty complex thing (a can of worms) and a hard way to get a good solution.
I can work work with Photolab as long as it stores all image processing settings in the dop sidecar and reads back external changes of a file set (raw + dop + xmp) instead of creating an unwanted duplicate (virtual copy) or even reverting the external changes.
My workflow depends on file sets (raw + dop + xmp) being independent from a single central database. I must be able to move around these file sets between directories or computers, make external edits, renames, backup/restore etc. All valuable information must be in the file set.
Information not being specific to Photolab raw processing must be accessible in open standard formats (XMP, embedded in Jpeg or as sidecar). OTOH, raw processing instructions shall not “poison” XMP data as Lightroom does. Consider people using more than one raw processor concurrently.
As I wrote I don’t advocate the removal of the database. The database is good for fast access. I simply don’t consider it the right place for long-term valuable information, and of course I don’t want Photolab to cripple my external edits.
5 Likes
Have you formulated a proposal for your wishes ? a Photolab-based solution to the keywords and other attributes would be welcome.
Whom are you asking?
It was intended for you, Obetz
Let me know which of my above statements were unclear.
Briefly: Regarding the topic of this thread, I agreed with John-M’s workaround which I’m using similarly. Besides, I wish that DxO doesn’t make it worse, or gives even more control over synchronization with external changes. For details, see earlier threads - it’s a long standing issue.
Dealing with metadata, especially synchronizing edits, is complex. One problem is the redundancy and ambiguity of the data (Exif, XMP, IPTC-IIM). Read the MWG guidelines (website currently down, use archive) and look at full-fledged DAM to get an idea.
There is a huge potential to mess it up.
So at the moment, I prefer if Photolab doesn’t touch my precious image metadata, although I understand that users would like to have a simple solution for a complex problem.
Oliver
2 Likes
I guess this is the reason why today the keywords are in PL’s database and not elsewhere. DxO must be trying to solve this challenge 
I use and trust exiftools to write directly into all my raw files (a copy because I keep the originals safe) so I have no use for a software that writes but I am okay if PL can read the tags if needed.
1 Like
PhotoLab without database means that every change must be written into a sidecar immediately - or at a later time through the use of some intermediate storage, which is exactly what the database does.
Writing stuff into the raw files defies the concept of non-destructive editing, so we need a database - or sidecars that will hopefully get less proprietary in the future.
1 Like
Right. Well.
With exiftool I am talking only about metadata since it is the most advanced tool for this specific task.
I am happy with the .dop file for all the edits of Photolab.
For the rest, time will tell us…
“non-destructive editing”, for me, means you do not loose quality when editing and the possibility to start over again… Writing metada to raw files is, for me, non destructive. But of course I keep originals safe because we never know what softwares - or the human - are up to until it is too late 
When are .dop files written today ?
When we switch from one picture to another ?
It would be great if the database is nothing more then a copy of data found in dopfiles and xmp-files.
indexing does speed up the search and regeneration of info from image’s. not preview of image’s.
(some but not much creating the filmstrip)
So if the Database is nothing more then a copy to speed up the library’s movements then it’s great.
The Dopfile’s and xmp files would then be the leading information.
This behaviour could be working when DxOPL can read edit write on xmp/dop/IPTC/fileproperties.
1 Like