I’m trialing DxO photolab. With Lightroom it stores edits in a catalgue. (It then creates endless catalogues with increasingly convoluted names as it forces a catalogue update on updates to the software). You can optionally tell it to create sidecar files (which in my case don’t always seem to be created but I think that is me).
How does this work with DxO? I’ve seen mention of sidecar files. Do these have to be enabled? Is there any use of a catalogue at all?
Thanks
Hi,
Yes You can activate the use of sidecar * .dop in the parameters where PL stores all changes in your images.
PL has no catalog but a database where these changes are also stored.
PhotoLab has its own internal database, which holds all image edits. There is no such concept as catalogues. Personally, I activate and us DOP sidecar files, which can then be transferred with the image file, to other locations on disk without messing up things like catalogues.
Even if the database were to ever corrupt, normally, these DOP files will ensure that your edits are safe.
Catalog vs database? They are different words for the same thing: A possibility to store information about image files and information about what we’ve done to them. Adobe calls it a catalog, DxO a database.
Catalog vs sidecars? I’d use both and my preferred setting is to not automatically import or export setting files (.dop sidecars). I prefer this setting because
Sidecars don’t cover all info that is stored in the database. Sidecars don’t contain the following:
If you use autoread/write of dopfiles then it can be usefull to create inside the folder that has the dopfiles and rawfile a extra folder “backup” and manual copy your dopfiles inthere when your done editing.
So if you accidently corrupt your dopfiles in the rawfolder you can use the backup versions to recover the orignal edting and dop version.
The database and catalog is official a cach and source for writing adjustments in the dop. This happens every time you switch from one image to the other.
Keywords arn’t inside the dop then you need to activate synchronise xmp.
So the information in the database is split in two files dop (edit adjustments) and xmp (gps, keywords, taggs that sort of stuff.)
Careful: While DPL can read and write both .dop and .xmp sidecars, the strict separation between settings and metadata is absent in DPL version 5 - which adds metadata (IPTC, keywords etc.) to .dop files. The consequence of this is, that the .dop files can almost replace a lost database, which is good imo.
XMP sidecars serve as metadata interchange between different apps, .dop sidecars are meant as PhotoLab’s own setting and metadata storage file, which is ignored by or unusable for external applications.
@platypus The use of the word “almost” is absolutely correct. My tests thus far have shown that PL5 does not appear to read the keywords from the DOP. That conclusion is based on what I have seen, but what I have seen will be conditioned on what circumstances I have deliberately tested or accidentally encountered, i.e. there may be a circumstance where PL5 will take the Keywords from the DOP currently in existence that I haven’t encountered or there may be something planned for the future!?
Disabling the auto DOP discovery option will prevent DOPs being used to provide data when you don’t want them to be used but if, after you have navigated to a directory containing DOPs when the option is disabled and later either activate the ‘Preference’ option or execute a ‘Sidecar’ ‘Import’ the chances are that you will be “rewarded” with a Virtual Copy.
I deliberately wrote that as “chances” because if the database entry and DOP are “related” with the same Uuid then that should cause no problem. However, if the directory is actually “new” to the database you are working with and you encountered the directory when DOP importing was “disabled” then the Uuid in the database will not match that in the DOP and a VC will be the result (if and when you cause the DOP to be read by PL5)!!
If you encounter a new directory while the import option is enabled then data will be taken from the DOP and the newly created database entry will effectively be a copy of the DOP (yet to check if any keywords will be copied into the database from the DOP rather than from the ‘xmp’ sidecar or embedded ‘xmp’).
This post probably has more caveats in it than any post I have written thus far!
…consequence of having to experiment instead of reading it all in a technical reference.
Just saved the .dops only and trashed the database. DPL does NOT read IPTC and keywords from .dop files. As you wrote, something must be cooking…
But it does read them, either from the RAW (or other) file or from an XMP sidecar.
The peculiar thing seems to be that, even if PL does write such metadata to a DOP file, it doesn’t seem to read them.
quite so. DPL is now rebuilding the database from scratch because of that test - and I see that it has just finished. It took 30 minutes indexing 25’000 items residing on an internal SSD. Note: Indexing takes into account all items, even if their surrounding folders are somewhere else, but added as an alias.
PNG files will not be counted though, DPL does not display .png files anyway.
@platypus I just ran a test where I set the DOP Ratings to 1, 2, 3, 4. The Photos Ratings were set to 4, 3, 2, 1 (JPG, JPG, JPG, RW2) in the actual photo (via PM) and Keywords were also set in the Photo including the RW2 (via PM using suitable settings to set directly into a RAW and not also create an ‘Xmp’ sidecar). I then added a sidecar with a rating set to 5.
I ran this once and believed that nothing was taken from the photo but I just repeated the test and I have included the snapshot. In this test I forgot to set keywords in the DOP and do not know what other factors (e,g, timestamps may influence the source of data used by PL5 but
Please note that there has been a change from PL4 to PL5, externally set Ratings would be shown in yellow on PL4 but no such distinction is made on PL5!
I need to repeat the tests as
Update 01:-
Settings the keywords in the DOP made no difference to the outcome and the DOPs quickly lost the Keywords when PL5 did a DOP update
Reading what is saved in DOP and what is saved in XMP and what is saved in the database – or not (btw. why a database if “everything” can be drawn out of DOP?) I’m always mildly amused. And strongly thinking, this app which needs so much additive sidecars and extra apps to be halfway functional deserves as much distrust as it’s mistrusting it’s own structures. Some stuff in the database, other stuff in DOP, why this super-redundancy? Apparently it needs loads of rescue anchors… and why @platypus has the database sometimes to be deleted? The longer I read in this forum the more I’m convinced there’s not much of concept for a safe way to organize images. Except the user ones of storing gazillions of folders and throwing tons of keywords to the images. Guys, you’re used to highly complicated structures. Great for you…
And btw. a catalog let me organize images in linked album, project or folder structures, without the need of additional Photomechanic apps or whatever and it simply works - if the devs were capable.
PhotoLab is transitioning to a solution that will be able to manage assets in proper ways. Until we get there, a few (serious) limitations exist and that we are trying to document in order to make DxO fix these limitations and progress PhotoLab.
Of course, we could all laugh at intermediate stages (and I don’t like these at all), curse at the database or walk away and do something completely different.
Hi Justin,
As you can see by the responses to your question, there are many different ways to work with PhotoLab - and that’s just one of the things I like about it. The way each individual chooses to work with PL depends on their specific needs/wants … For example, I don’t care about keywords, and I’m wary about depending on the database to never get out-of-sync or whatever … So, I definitely have automated settings (via Preferences) for use and updates of sidecar/.dop files (which is different from Platypus’ approach).
Have all your questions now been answered in the responses above ?
John M
But I for one would miss the editing facilities that I find relatively straightforward and mostly intuitive to use. Unfortunately this has been a really chequered new release and, as @platypus states, hopefully the efforts of those testing will bear fruit and the product will become better as a result of the effort.
Unfortunately a lot of errors came about during the upgrade release from PL4 to PL5 (and again from PL5.0.? to PL5.1.?. During Beta testing that (the release/upgrade) was never tested and might have been difficult to test because the machines of the Beta Testers would have been “tainted” by having many and various Beta releases on their machines.
This would not represent the expected state for all non-beta testers i.e. they will go straight from running PL4 to installing and running PL5 with the associated database etc. upgrade.
However, I would respectfully suggest that it is thoroughly tested as part of PL6 Beta Testing. I would also respectfully suggest that more information is forthcoming from DxO and a much greater interaction between Beta Testers, Forum contributors and DxO would benefit the whole user base greatly and problems might be avoided altogether or corrected much quicker.
I have not used a cataloguing system at all until my rash purchase of IMatch the other day. I use Photo Mechanics because it offers a lot of facilities for adding metadata to photos and includes options to change RAW images directly. Hence, the nature of the tests I have been running which include the PL4 database, the PL5 database, DOPs from PL4, PL5.0.1 and PL5.1.2, embedded ‘xmp’ metadata in JPGs and RAWs (RW2 and ORF in my case) (courteously of PM) and ‘xmp’ sidecar files.
The problem is not the number of elements involved but was the strategy for determining what should be added where and taken from where correctly defined and then was it correctly programmed, and the answer appears to be NO under certain circumstances but while I might be able to show errors only DxO know which it is or whether it was both or …
Dear Bryan,
thank you for this execution, especially paragraphs 4 and 6 of your post.
During the EA5 test many members tried to get information what was already fixed, what is still in the pipeline and so on, but the information flowed sparsely. You can see this in many posts about UI, Win/Mac differences, DB/DOP/XMP …after the release. I’m not participating in the upcoming beta test, but once again urge DXO to implement a more structured approach. The forum and the cooperation of the people is so great, but a lot of effort and passion just burns here. Perhaps a small, simple Testmanagemnet Tool would be to be considered, in which each beta tester sees at least the reported errors. Since until now after each EA version there is a new structure to report the bugs, there is a lot of information loss here. I already pointed this out several times during the EA phase. Maybe it will work next time.
Have fun 
@platypus you know that I agree with this statement from all the comments that I make but I am sorry that I “ignored” it and wished to say that I thoroughly agree that we should be able to review documents either to better guide any testing we do or remove the need for testing entirely and would like to see more feedback with new releases and more visibility of DxO in some of the forum topics.
Now for a little more testing before more important things like fixing the central heating! The (very old) boiler failed on the 23rd. December with a thermocouple fault which the plumber we use came and fixed last Friday. However, my wife discovered wet towels at the top of the airing cupboard and investigation showed that a zone valve is leaking!
Normally the heat from the system has been evaporating the water from the slow leak before much harm was done but not while the system was out of commission for so long. I replaced one failed valve over a year ago and have replacements for the other two so out with the spanners and a different kind of “engineering”!!
While a beta phase can test update mechanism, prod. updates come up after testing by DxO only. Due to the number of variables and dependencies in such an application, it’s virtually impossible to deliver bug free software.
We are well advised to back up DPL’s database and run our own tests before letting a new release loose on our precious files. After a few months, quality improves… and then, a new major release is published.
User guides exist, but they are mostly meant to promote features rather than background information, which is often stored in heads and internal sites rather than made public. Questions like how and why often remain unanswered…
@Guenterm I have signed up for the next Beta Testing but have spent way too much time testing PL5 just recently and may have (sorry, have) annoyed my wife although thoughts of DIY or gardening or photography have been crushed by the weather which has been so grey and gloomy but I do need to get the tools out today to replace the leaking central heating valves.
I installed the valves into a very old (open vent) system back in 2007 when we bought the bungalow from my wife’s parents. The hot water cylinder was replaced by me later that year I have attached one of my “finest” photos (joke!); although I feel that it is a reasonable bit of DIY plumbing!
And for any heating engineers in the audience the valve from the top of the hot water cylinder is zip tied open but is there if I need to use it in an emergency, with the system down of course.
