No Photolab SDK ? Something can be done

Pat91 · November 28, 2025, 12:33pm

Hi,

A recent post in this Feature Requests forum (Suivi des copies virtuelles) gave me an idea about the lack of a SDK for Photolab.

I don’t think that a programming interface allowing to develop plugins for Photolab will appear anytime soon. However, something could be done to allow third-parties to provide additional functionality to Photolab.

Let’s assume that, under the Projects entry in the left panel, we would have a “Custom SQL requests” available to the user. This would allow anyone to use the PL database in order to apply some modifications to a selection of images or to output a list of images corresponding to a particular criteria.

In the first case, a message could be displayed at the end of the process or, in the latter case, the images listed in the output would be displayed exactly as they are displayed when selecting a project.

Of course, the request could be stored for later use and the dialog used to enter the SQL request should be able to accept a few parameters. writing such a “SQL requests manager” is trivial.

This way, SQL knowledgeable users could share a few useful SQL requests that could be used by any user.

From a development point of view, this is much easier to implement than writing a more comprehensive programming API.

I had this idea because a user was looking for a way of knowing to which project(s) an image belongs. The necessary data is present in the database but the Photolab UI uses these data only for displaying the images belonging to the currently selected project (by the way, this particular request from the user is easy to satisfy - just display this information along with the information already displayed in the popup appearing when hovering the image in the image browser).

This is just an example but I’m sure that these “Custom SQL requests” could be used to compensate for the weaknesses of the DAM part of Photolab.

Joanna · November 28, 2025, 12:51pm

An interesting idea but… have you looked at the PL9 structure? I see foreign key columns with the name ITEM and one of several suffixes, which indicates to me that they might be forwarding from one version to another for migration purposes.

Anyway, as I have mentioned before, DxO doesn’t adhere to SPOD and what with the database, DOP files, XMP FILES, etc, maintaining connections between the MPODs could be a nightmare.

And I still haven’t found a path through the keys to virtual copies, which seem to only exist in the DOP

upoint · November 28, 2025, 1:42pm

“trivial”

I always have a good chuckle when I read statements like this on a user forum.

Pat91 · November 28, 2025, 3:43pm

Some users can be developers. And very frankly, allowing the user to store an SQL string and retrieve it when needed is even easier than managing presets.

Checking and executing the SQL request and managing the results is nothing like trivial however. But much easier than writing a programming interface.

upoint · November 28, 2025, 4:36pm

How well I know. I’m retired after a long career in software development with a variety of job titles.

But when I see the word trivial used (especially by someone who should know better) it tells me the writer does not have a grasp of the “big picture” of software development done by a team of programmers, for an audience of thousands, over many years, if not decades.

Pat91 · November 28, 2025, 4:50pm

In the database, original file and virtual copy appear as 2 different records in the Items table having a different ID, and the same sourceID. The item representing the virtual copy has an additional setting : LocalParametersVersion=n but I’m not sure about what the value of n represents. The Sources table appears to be completely unaware of the existence of any virtual copy for a given item.

I admit that the structure of the PL database is rather simplistic compared to the Lightroom database. This can make writing SQL requests more difficult than it should be. But if they could be so kind to provide some technical documentation about the database, it should be possible to implement the suggested idea for basic features.

Pat91 · November 28, 2025, 4:59pm

Again, I have used the word “trivial” about a possible “request manager” that would only have to store a few SQL strings, delete them or recall them when needed. That’s all and that is indeed trivial.

The rest of the job is obviously more complicated, especially because the database structure is rather rustic. But that would be less complicated than implementing a programming interface (I know, I already wrote one).

Shad · November 28, 2025, 6:05pm

Hello Pat91,

Forgive me butting in, but I am curious as to what problems you’re trying to solve through automation? I’m genuinely interested in your use cases.

I enjoy wild life photography, so I tend to take over 1000 photos on a good day. This results in a lot of photos that are sequential, so it’s not so hard to take the first photo, apply some changes, then copy them to later photos.

What’s hard for me is quickly telling what’s a good shot or not. I will step back and forth between photos before choosing best, OK and dross. So speed is important to me.

What are the obstacles you face in your photography?

Best regards,

Shad

Shad · November 28, 2025, 6:28pm

Hi Karl,

With the greatest respect, and coming from a fellow developer, any request should be considered, not dismisses without assessment.
And, unless you are employed by DXO, you are not equipped to assess, nor am I.

In the narrow context of a piece of software, anything is possible, but not necessary economical.

Economical development depends demand, should DXO implement a new feature, they look at demand and competition. There is also crowd funding where, if enough people commit funds up front, a feature gets developed.

My point is a closed minded attitude is not productive to the development of DXO, or any software.

Best regards,

Shad

BHAYT · November 28, 2025, 6:59pm

I apologise for the number of spelling erros (errors) that were in the original post!!??

@Pat91 The ‘Sources’ structure might be ignorant of the the existence of ‘Virtual copies’ actually of copies, including the [M]aster but the index on ‘Items’ certainly isn’t!?

As Virtual copies are added to the ‘Items’ structure, so an additional entry will be added to the ‘idx_Items_SourceId’ index with the same ‘SourceId’.

So the first entry located is the [M]aster and the other entries with the same ‘SourceId’ will be found one after the other in the same index.

As far as I can tell that is the only way that PhotoLab can/does keep track of the VCs!?

The ‘LocalParameterVersion’ is part of the ‘Settings’, and hence, included in the DOP but has no significance I believe. In the following test the first two entries contain the same value of “2” and one of those is a [M]aster and the other VC[1]!?

In Windows DOPs all entries are in the order [M], VC1, VC2 etc.. but those from a Mac appear to not be in such an order. The “correct” order can be restored for MAC DOP copies by sorting on the ‘CreationDate’ timestamp or so some tests I undertook some time ago showed.

So the entries after a mini test

Image submitted via FastStone Image Viewer
VC created in PL9.2.1
New Folder created in PL9.2.1 and the image in step and the VC in step 2 copied to the new directory.

Are in the following, the ‘Folders’ structure in PhotoLab.db

There is nothing obvious in the database entries and no keys use the ‘CreationDate’, arguably an “obvious” way of distinguishing the order of copies.

However, the order in which they have been added to ‘idx_Items_SourceId’ effectively signifies that order. As a database consultant for 36 years I am afraid I would not rely on that and would have included the ‘CreationDate’ with the ‘SourceId’ to create a composite key of ‘SourceId’,‘CreationDate’, which I believe is possible in SQLite.

Addition:-

On Windows, copies cannot be named. In addition any VC created from an existing VC or the [M]aster will automatically become the last entry in the index, i.e. be added at the end of the existing entries with the same ‘SourceId’

When one is deleted their entry will be removed from the index and the remaining copies with simply “shuffle down” or so it will appear.

Given how “crude”, sorry “trivial”, the process is there is absolutely no reason why the [M]aster cannot simply be deleted!?

upoint · November 28, 2025, 7:04pm

I object to characterizing a hypothetical new feature as “trivial” as a way to shame a company into implementing the feature.

If DxO wants to do it, fine. But I think DxO, not me, have declined to create an SDK for their software.

Shad · November 28, 2025, 8:48pm

Hi Karl,

You talk in terms of software development and that is exactly the context that I am replaying to you in. I don’t care about your personal attributes. I am critiquing you on a professional level as to why you deem suggestions as objectional.

It is not for you, or I, to deem suggestions as “objectional” when we are not on the DXO dev team, is it?

Indeed, the presumption that our opinions in the context of DXO should in some way be more relevant than anyone else would be utterly hypocritical, would it not?

Einstein was a Patent Clark after all.

Respectfully,

Shad.

Pat91 · November 28, 2025, 10:07pm

I’m just giving some thought about how to find a way to fill the gap between Photolab and Lightroom regarding the DAM part of both applications. Since providing a SDK has never been an option for DxO, maybe we/they could find a less costly/easier way of letting third-parties routines interact with the program.

I’m not trying to solve a specific problem. Most of the time, I’m using DPL from Lightroom.

andras.csore · November 28, 2025, 11:08pm

Yep, I think PL db don’t have a concept of VC numbering (as stored value). For the same sourceId the first (smaller) item.id is the ‘Master’, and all other (larger) is the VC order by item.id. And vc1, vc2, vc3 is just calculated on GUI on-fly.

andras.csore · November 28, 2025, 11:30pm

Actually PL has this nice stuff (SQL query alike):

And yes, its filter down the photos (library):

Guide (search functions):

May its can be improve like “save search” (not just last searches), better field type selections (what a bit of messy for me), etc. I can image like: right click (on the Search for images) → and popup list come to select field(s) (like FocalLenght, ISO, Shutter, etc. ). However, its raise nice already → show with cute icons.

So, ‘SQL select’ already there in a way.

platypus · November 29, 2025, 6:18am

Looks like something that Adobe calls a Smart Collection.