Hi,
I know that I’m probably being difficult but I often rename my raw files using a home grown application from outside DxO Photolab. Very briefly I write keywords to .xmp sidecar files and then rename the raw image, xmp and dop files so that the keywords become part of the file name. Unfortunately, if the .dop files (DxO edits) contain virtual copies this reaming causes PL4 a few issues .
The problem is that the .dop file lists the file name in a name tag once per virtual copy. I make no claim to understanding quite what happens but the data after the name tag is used as a display name and in any exports of that virtual copy. It seems that the link between the virtual copy and the raw file with the new name is maintained by the “database”. While experimenting I have had some virtual copies displayed with the new name while others are displayed and exported with the old which is confusing.
I have not found a command to force an update of either the dop file or to have the database re-read the parent folder of the files. I do note that some order is restored if the database is trashed and the raw file is loaded into customise, edited and then saved. Its o.k. for a single file but not so good for hundreds.
I do wish that there was an option to just use PL4 as a raw editor and switch off the DAM aspects of the application.
Greetings,
I understand your use case, but consider this.
DxO has matured as a product. For many years people have compared its DAM capabilities with Lr, and blasted it for what some described as inadequate capabilities. It never bothered me personally, so I placed less value in it. DxO has since put great resource and effort towards addressing these “concerns”. While DAM isn’t as important to me as others, I don’t think we will see a reversion to a less functional product in this regard. As you have already found, manually editing .dop and sidecar files results in unexpected behavior. I’d expect that for sure.
I don’t know if developing a feature to turn this function on or off would be considered. Maybe you should add it as a feature request and see how many votes it gets.
Took an image and created two VCs. Exported the sidecar and edited its content in a text editor.
Imported the sidecar and it brought back the VCs with the names I put in the sidecar.
Original file name ended in 8866, I added a 1, 2 and 3 respectively and I got file names ending with 88661, 88662 and 88663 on both the raw and exported files.
For a complete rename, the sidecar’s content must be edited too.
I have cast my vote but the reality is that while PL4 is an excellent raw processor its DAM capabilities are lacking which means that the only options are Adobe Lightroom or a home brew system based around a third party DAM.
There are more DAM options out there and some have been mentioned in several posts. Nevertheless, DPL is progressing slowly in this field and I assume that it will take quite a while until DPL’s DAM functionality can equal what some of the contenders can already do.
Meanwhile, it’s good practice to keep whatever DAM you have and use DPL for what it is best, which is (almost) everything but DAM.
Whilst it’s no consolation to you, Simon … I do exactly this sort of rename process too, and it works just fine on the Win10 version of PL (providing one keeps the image+sidecar filenames in-sync, of course).
For me, it’s essential behaviour by PL - as I can use a far more powerful (3rd party) renaming utility than relying on PL’s simpler tool-set.
@joanna: I recall you had some discussion on this issue for Mac users - - but I cannot find it … It may be relevant for Simon (?)
No - It was one about the issues you encountered (Mac only) when renaming {image+sidecar} combos … and encountering problems in doing so. (Perhaps I imagined it !?)
#John-M . Interesting post. So just so that I am clear, from time to time you conduct file renames, outside DxO, of a group of files in a directory that include files that have been edited in DXO PL i.e. they have .dop files. When doing this the Windows version of DxO registers the name change the next time you view the files from inside DxO?
If I have understood correctly then it would imply that the Mac version has a bug in this area.
In response to Platypus’s comment about other DAMs being out there : yes that is the point of my post. My DAM is based around an application named NeoFinder plus some scripts that keep the ,dop file names in sync with the parent raw file name. This works well except for Photolab getting in a muddle (programming term!) over the names of virtual copies which appears to be a lack of sync between the data in the .dop file and the PL database.
My short term solution is to update my scripts so that the file names inside the .dop files are updated with the new file name. This is untested at the moment.
Modifying the .dop has revealed another unfortunate feature or design of the DxO Photolab in that it does not store keywords in the .dop files.
Yes - There’s no problem whatsoever in renaming {image+sidecar} combos from outside the Win10 version of PhotoLab (provided one is careful to retain the same main filename for both parts of the pair - AND provided the renames are executed quickly enuff that PL does not discover what it thinks is a “new” image without a corresponding sidecar) … PL even repairs/updates the filename stored within the sidecar. I do this all the time - including (tho, very carefully) when PL is actually running.
Well, at very least, it’s an anomaly !
Yes, that’s a known limitation (for the Win10 version too) … Not something that concerns me, tho.
As mentioned above, you have to edit the names within the .dop file to rename virtual copies. Then import the changed sidecar in order to get the info from the sidecar into the database. Note that filenames edited in the sidecar are independent of the file name, at least in my tests…
