DPL 6.9 Win - Option "Load settings from sidecar files automatically" doesn't work

DxO PhotoLab Windows topics
1

Hi,

I just discovered that any change made manually to a dop file is not taken into account when re-launching DPL even if the “Load settings from sidecar files automatically” option is checked and even if the timestamp of the DOP file is more recent than the last change in the database.

However, importing the DOP file from the File | Sidecars | Import menu works.

There’s another annoying behavior of this function : “Import” doesn’t allow you to select a particular DOP file. It just looks for the DOP file having the same name as the image file. This prevents from having a set of multiple DOP files for a single image (which can be useful in certain circumstances).

Am I alone with this issue ?

Thanks.

2

Before anybody asks : yes, when changing settings manually within a DOP file, I also update the various timestamp fields like Date and ModificationDate.

3

Well, not that simple. Sometimes it works, sometimes not. I guess that manually modifying a DOP file requires having information about how the change detection is made when automatic mode is enabled. Maybe a minimum time laps is necessary between the timestamp in the database and the time stamp fields within the DOP file ?

It seems that making manual changes in these sidecar files is not a good idea.

4

I discovered that a long time ago.

In fact, I tried to write an app that would parse DOP files, so that I could “tinker” with them in a structured way. unfortunately, it would seem that DxO have used a format that is fairly much incompatible with the majority of serialisation layouts. It’s, sort of JSON, sort of XML, sort of Plist.

But none of the industry standard parsers can do the job out of the box. And, despite my many and best efforts at reverse engineering, I still haven’t yet been able to parse it reliably.

5

Have you tried with automatic import/export disabled?

Tested switching settings in two images (without bothering about timestamps)
and the exchange worked as expected - with DPL 6.9.1 on macOS 12.6.9
Screen 2023-09-18 um 22.48.31.161.mov.zip (11.9 MB)

6

Hi Joanna,

Actually, the format of the DOP files is LUA. I just noticed this. Yet another strange discovery in DxO’s code. I have never seen apps developed with the Microsoft.net framework and using such a strange format to store data instead of XML. The framework has all necessary tools to manipulate XML and they jump to LUA ?!?!

Maybe it’s to make the interaction with Lightroom easier ?

Developers sometimes make strange decisions. I always considered the choice of LUA for developing parts of Lightroom as a big mistake and now I discover that this maybe also affected Photolab.

7

Yes. Same results. I will not insist of investigating this. As Joanna said, this would require doing reverse engineering with the database and I have no time for this. Many years ago I did this with the Lightroom database in an attempt to analyze a similar problem which I described here :

This was too much efforts for a very disappointing reaction from Adobe.

8

I thought LUA was a programming language, not a data encoding syntax.

The main problems I had were with the use of { and } to surround both composite types and arrays and the adding of a comma at the end of an array.

How am I meant to determine that…

	GridWarpingGrids = {
		InputGrid = {
		},
		OutputGrid = {
		},
		PointsPerColumn = 0,
		PointsPerRow = 0,
	},

… is a composite type that is meant to have curly brackets and…

	KeystoningPoints = {
		0,
		0,
		0,
		0,
		0,
		0,
		0,
		0,
	},

… is an array that is meant to be surrounded by square brackets?

Both have an unnecessary comma before the closing bracket.

Or am I meant to deduce that composite types will always contain an element name and an assignment operator, whereas arrays won’t?

The problem is that Swift for Mac, as .NET for Windows, doesn’t have a ready-built decoder and, so far, mine still chokes on my parsing algorithm.

9

Joanna,

Yes, LUA is a scripting language but the format it uses for serializing data is also the format used for DOP files. This can be confirmed by looking for example at Info.lua or Plugindata.lua in any Lightroom plugin folder.

I had a look at the folder where the Photolab executables resides (under Windows) and I noticed that there are 3 LUA related (.Net) DLLs there :

LUA51.dll (not DxO - part of the LUA runtime developed by LUA.org)
LUAInterface.dll (not DxO - copyrighted Fabio Macarenhas / Kevin Hester)
System.Lua.dll (this one is from DxO)

Using ILSpy (a free .Net Decompiler), it’s easy to see that system.lua.dll contains a LuaSerializer class that is obviously here to write and read DOP (LUA) data files. Not documented by DxO, of course, but it should be easy to use from a Microsoft.Net application by a developer having some experience in .Net coding.

I really don’t see where in the roundtrip between Lightroom and Photolab, the latter could need to read, write or exchange data in LUA format with Lightroom. But I can’t find any other justification for the use of the LUA format for serializing image settings. XML should have been used from the beginning right away. Using XML would allow third-party developers (you ?) to write programs accessing and manipulating an image settings. The serialization code is already available in the .Net framework. No need for these 3 LUA DLLs.

If any DxO representative could explain, I’d appreciate.

My two cents.

Patrick

1 Like
10

While exploring the DxO, DxO Labs and Nik collection folders, I also found other LUA data files like Frames.lua, Defects.lua, Textures.lua, Blurshapes.lua… They are obviously configuration files for various features, making these features potentially user configurable.

So, the use of LUA is probably not related to Lightroom. It’s a deliberate choice for the serialization of various data, including the DOP files. Well, it seems that the LUA infection is widespread :smiley: . Time to move to the standard : XML.

1 Like