Hello Dears, I edited by RAW in dxo and then batch-changed the file name in a different program. This lost the connection between the RAW and the DOP file. Both files are still present in the same folder. I tried to rename the RAW back to the old name, but that just creates a new DOP file. How can I reconnect the renamed RAW file to the original DOP file, or import the edits from the DOP file, please ?
Change each âName = âfilenameâ,â setting in the DOP file (for raws and jpg, if present) and rename the DOP file to match the RAW name. After starting PL and changing to that directory, PL should update its database automatically. I donât know if using XMPs would require some extra actions. Tested on PL7/Win.
Edit: Some cameras include original filename in the raw file metadata, so you can use that in a batch (+exiftool), if your renamed filenames contain no clue about the original name.
I have gotten into the habit of only renaming files in DxO or outside DxO only before opening them in DxO for the first time. Renaming within DxO affects the RAW file and .dop and .xmp. In your situation, the only option is to rename the .dop and .xmp outside DxO.
Yes, I usually rename the raw files immediately after importing them, before opening them in PL. But well, things happen. Many thanks for the trick to rename the .dop file and edit the filename info inside the .dop file. In the present case, however, I may chose to edit the 20 photos again rather than spending time copy-pasting file names. I would have appreciated a solution like Image:Apply corrections:from a .dop file. Should I file a feature request for next time ?
@Wlodek I believe that changing the name in the DOP is unnecessary on Windows but that might not be true on the Mac version. DxPL(Win) updates the DOP with the new name when it writes it back to disk.
The original entries in the DxPL database will be âorphanedâ.
As for the xmp sidecar, DxPL certainly doesnât put the name in the basic xmpâs it creates but other software might!?
You are right. Sometimes âsicher ist sicherâ attitude is an overkill, but I couldnât resist.
Do you know if PL cleans the âorphansâ automatically, e.g. when (re)entering directory?
Never!
Entire directories can remain orphaned in the database, even more if you changed to another disk with the same structure but a different id (I have discussed that issue in other posts at excruciating length!!)
Hence, the recommendation that changing names etc. is done within DxPL whenever possible!
The lost space is not an issue (except an ever increasing database size) but external actions can lose âProjectsâ pointers on Windows and âProjectsâ pointers and 'Advanced History on the Mac (I believe) and create dead wood in the database on both systems.
1 Like
Thanks for pointing out possible problems with Projects (in my plans for the future).
Perhaps DxO should add âDatabase cleanupâ button, but that would be risky, because many users would not be patient enough, to wait for the process to finish. Still, I found PL to be quite tolerant to file/directory name changes, compared to some other software, since PL does some DB and cache updates on each directory change. Never had time/reason to work out the details and didnât find a âtrustedâ explanation either, e.g. by DxO.
PL DB size depends also on how many Local Adjustments were made using a brush. Normal Settings take about 10KB, while LA brushing can make it hundreds of KB, all in DOP and PL DB. Itâs not an issue for me but maybe for some it might be (?).
Unique disk IDs (e.g. scsi pages 0x80, 0x83) and GUID is a Microsoft and disk providers problem, that you can see also outside PL, especially in NAS environments. It was even much worse with older Windows versions, when Microsoft started to enter the server market, with clustering, multipathing, etc. Itâs yet another (not-so)funny story about not having competent staff, just like much older Win NT vis OS2 story. But they are making progressâŚ
@Wlodek this has been asked for many times by others and by me - very unlikely to happen. DxO even managed to cripple the indexing process going from PL6 to PL7 (on Windows) and turned it from a background process to a foreground process.
If the directory is âin scopeâ when the external change takes place then it is good at making the adjustments there and then. But changes made and discovered later are generally treated as ânewâ directories and the old entries are left to ârotâ.
It is these changes that leave âProjectsâ pointers âhangingâ, DxPL follows the internal database pointers and attempts to locate the associated directory only to discover ânothingâ and that results in this
In this situation the âFix Image Pathâ will appear for the âhangingâ image pointers in a âProjectâ, i.e.
BUT only for âProjectsâ and there are potential pitfalls to be found there as detailed later in the post!
DxPL is driven by traversing images on disk, adding them to the database or using the DOP found on disk to update the database (possibly with âUnwanted VCsâ) but not via the database.
Hence, there is no way for it to discover that external renaming has occurred automatically except in the case of âProjectsâ when pointers to disk images no longer work!
A reconciliation process needs to be driven by accessing image/directory entries in the database and attempting to locate them on disk and either abandoning the database entries (garbage collection) or offering the option to âFix Image Pathâ to the user.
When I first retested with the external renaming to (re)test the âFix Image Pathâ for this post DxPL doubled the number of VCs but trying to reproduce that issue today has so far failed, i.e. the tests have been well behaved thus far!
Until I remembered the scenario that causes the problem, please see the end of the post for details.
Agreed. I donât do much LA so it doesnât affect me much but could affect others greatly!
DxPL uses the id to prevent âconfusionâ with the drive letter (or so I believe), e.g. for handling external drives that may come and go, but the user then runs into trouble when a backup (or new) drive is substituted.
When I experienced the problem with digiKam it offered alternative courses of action but DxPL simply ignores the issue and assumes that the disk is to be treated as ânewâ and leaves the old database entries alone and adds the disk as new entries!
The current fix requires database âhackingâ, which is particularly easy for NAS drives, but could easily be handled by DxPL itself! If possible the NAS issue can be avoided with DxPL by changing the mapped drive letter, providing that does not upset any other software!?
The problem with âFix Image Pathâ under certain circumstances:-
Using âProjectâ pointers to locate database image entries that have become âdetachedâ from the physical image entry works fine providing that the user has not already discovered the renamed directory by navigating in âPhotoLibraryâ.
If the newly renamed directory is discovered by the user directly with DxPL the images in the renamed directory will be added to the database, so there are now the old âorphanedâ entries with the name of the original directory and the new entries with the new name of the directory in the database.
Undertaking a âFix Image Pathâ to (re-)attach the images in the new directory to the âProjectâ has real problems with âUnwanted VCsâ as follows
The âProjectâ with the âmissingâ images & the âFix Image Pathâ command:-
Locating the original images in the new location:-
The impact on the âProjectâ - now pointing the additional VCs:-
The image directory complete with a lot on âUnwanted VCsâ in this case:-
DxPL(Win) hasnât fixed the path for the project in this case but rather it has added the original image data in the database to the ânewâ (renamed) image data in the database.
I feel that this is wrong and wonder what the original DxO rationale was for doing it this way!?
It certainly preserves the original data in the database that is for sure but it poses another problem because the âProjectâ in my test case now points to the original entries but these are all VCs.
While it is easy to isolate and delete VCs, in this case that is all there is in the âProjectâ so âfixingâ the problem by deleting the additional VCs will empty the âProjectâ hardly what I wanted to accomplish!