Best Process for Bulk Rename After DxO is Aware of the Images

DxO PhotoLab
#1

I want to bulk rename files that I have already looked at (therefore, cataloged) in DxO. My main concern is avoiding cluttering DxO’s catalog. I understand it is best to move or rename files from within DxO to avoid this. However, there does not appear to be a way to do this in bulk from within DxO, and not in the custom name spec that I am using. So I’ve written a Python script to handle the file renaming. (It’s a long story… Suffice to say that I had issues with various other bulk renaming tools.)

There are two classes of files… The main one is files I haven’t edited at all yet. So there is really nothing to preserve. I could (if there is a way) delete them from the DxO catalog, rename, and then browse to them again via DxO’s PhotoLibrary to re-catalog. Does that sound like the best option, and if so how do I delete them from the catalog?

The second class of files are those that I have already edited… I assume there is no good way to bulk rename without losing my post processing work. The renaming is not worth that. But if anyone has any magic ideas, I’d love to hear them. (Does DxO have an api or other “hooks” that could be used to tell DxO to rename a file in a way that would preserve the connection to post processing?

Thanks in advance for any info.

#2

@HumanJHawkins , do you use PhotoLab on Windows or macOS?

#3

For batch renaming you’ve got this when selecting several images in photolab image browser :
(F2 shortcut - same as windows shortcut)

Rename2

Photolab 6.3.1 PC here.

#4

Windows. Thanks.

#5

Thanks. I didn’t realize any bulk rename was in DxO Photolab yet. But I’m wanting to rename based on shot date/timestamp plus the original file name… The names are like:
20230522_PM0728_DSC02547.ARW

The reason is so sorting by file name will also sort by shot, even after my stupid Sony camera resets it’s counter back to 00001 every 10,000 shots. Also, just like having that shot time info right there when I’m scrolling through them. Haven’t found a reliable way to do that aside from writing my own script.

#6

I suspected that you’d written a script to add metadata to the name. No option in photolab batch renaming for that.

#7

You can use exiftool to do this.

1 Like
#8

You can do this (and more) easily with this tool,
but before you start PL and its database.

screenshot #1 shows the included → time stamp (= inserted from metadata) in my filename
to ‘automatically’ discern & sort the pics from 2 cameras

#9

PhotoLab (Mac) tracks changed filenames, if the surrounded folder is selected in PhotoLab’s sidebar. This enables renaming using external utilities, but it also means that it has to be done folder by folder.

If I wanted to rename all of my files across the complete archive, I’d probably disregard DPL database sanity and do it like this:

  • Make sure that all sidecars (.dop and .xmp) are up-to-date and next to their photo files.
  • Point PhotoLab to an empty folder, quit DPL and rename its database (enable fallback)
  • Rename the lot (image- and sidecar files)
  • Start PhotoLab and index the archive
  • Wait until finished, then review the result and decide for/against fallback

Warning: This procedure will loose projects and customizing history. It’s therefore advisable to test the procedure with a copy of a part of the photo archive.

#10

I use PhotoLab 6 only to edit RAW files, and I’m not interested in using it for anything else like organization, metadata, etc. For that I use Photo Mechanic.

So like the O.P., I too need to be able to rename outside of PhotoLab. If I rename with Photo Mechanic, my RAW and .dop files are automatically renamed together, so I would have thought that as long as the RAW and the .dop files match, it shouldn’t be a problem (it never used to be an issue until they started adding DAM abilities).

A major issue after renaming is edits being applied to the wrong image. As an example, lets say I have 4 files: Test0001.orf, Test0002.orf, Test0003.orf, Test0004.orf. I decide to delete Test0002.orf, and rename the rest so that they are sequential. So Test0003.orf is renamed Test0002.orf and Test0004.orf is renamed Test0003.orf.

Now if I open the newly named Test0002.orf in PhotoLab, the correct edits have gone, and instead it has taken on all the edits from the old Test0002.orf. And the newly named Test0003.orf has taken on all the edits from the old Test0003.orf. Sometimes the above procedure will also create random virtual copies of some images, in addition to having the edit info mixed up. It’s a complete mess that is impossible up undo.

I always thought it was the .dop file and only the .dop file that provided the instructions telling PhotoLab what edits you made to an image. But I’ve since read that PhotoLab also stores the edit information in its database. So the errors above must be due to PhotoLab ignoring the correctly-renamed .dop file and using the info from the database instead.

I’ve discovered that if I rename the image folder before opening the renamed images in PhotoLab, the above errors do not occur. I assume it’s because PhotoLab does not recognize the folder in its database so it is forced to use the .dop files instead. It’s an ok workaround, but if I forget to rename the folder I’m in trouble.

This is something DxO really needs to fix. Maybe there needs to be an option to tell PhotoLab to only use the .dop files and not to store edit info in the database. Or for those of us (and there’s plenty from what I’ve read) who aren’t at all interested in PhotoLab’s DAM abilities, it would be really nice if there was an option to switch off the database completely so that PhotoLab was strictly an image editor.

#11

This only happens if the renaming is done without DPL being pointed at the very folder in which the to-be-renamed files are (or DPL not running at all). If the files are renamed in DPL, everything will be okay, if the files are renamed by the Finder (I’m talking Mac here) and DPL sees the files whilst they are renamed, DPL adapts in less than a second and everything will be okay. Still, renaming in both of said ways isn’t very practical for bulk renaming…unless all files are in one fat folder :wink:

#12

I don’t necessarily have DPL running when I’m organizing images in Photo Mechanic, but I’ll have to give that a try, thanks. You’re right though, not very practical. I hope DxO addresses this.

#13

Just did another few tests with PhotoLab versions 1 to 6 on macOS and found that all versions had “miraculously” more tolerant to file renaming. I’ll have to investigate this some more. Your best bet is to test thoroughly before going bulk…and to keep a backup for fallback.

Back after more testing…and still on Mac:

Test 1

  • Quit DPL
  • Change file names with Finder
  • Open DPL → PhotoLibrary shows the changed names
  • Quit DPL → The database renamed the files, no duplicate entries, no VCs!

Test 2

  • Quit DPL
  • Change folder names with Finder
  • Open DPL → PhotoLibrary has to be directed to the renamed folder
  • Quit DPL → The database added the renamed files → duplicate entries, but, no VCs!

If this behavior is what happens on your systen, a bulk rename should be possible when acting like in Test 1. Sidenote: I select an empty folder before I quit DPL.

All tests done with the latest releases of DPL versions 1 to 6 running on macOS 12.6.7 (latest Monterey) on 27in iMac 2019. All tested files had no sidecars, which is why it probably worked as it did. Hint: no issues caused by sidecar UIDs and -timestamps.

#14

If you rename in a DAM software usually all sidecars get automatically renamed too - so PL will not have a problem then.

#15

Agreed, if PhotoLab only considered file names. Due to many other posters’ research, PhotoLab seems to consider file content too, like a UID and probably a time stamp. Differences between UIDs and timestamps (stored in the files vs. stored in the database) can create virtual copies and other inconveniences like false positives in search.

If we assume that all .dop files are present and up-to-date, we could a) rename the files in Finder/Explorer/App, b) trash the DB and c) let PhotoLab index the renamed lot. History and projects would be lost in this way though.

#16

I use Photo Supreme as my DAM now for years and delete, rename etc… quite often and regularly within PSU. In all those years I have never ran into any problems with DPL. The only thing I do consistently is “only use ONE software for metadata management” - in my case Photo Supreme. I do NOT touch metadata in DPL.

#17

Even with correctly named sidecar files there is still a problem because PhotoLab looks at its database first, not the sidecars. It only seems to read the sidecars when it sees images that do not already exist in the database.

In my experience it seems to depend on how you rename files. If all the new filenames are completely different, or if they are put into a new folder, the database does not recognize them so PhotoLab will use the dop file to load image data. In those cases everything works out ok. If you name/rename the way I described in my previous post (when some of the new filenames match previously used filenames) it’s a disaster. There are other circumstances too that seem to cause random issues (unwanted virtual copies etc).
I think what’s happening is that you’re renaming/reorganizing in such a way that you’ve been fortunate enough to dodge the issue. But there is definitely an issue.

#18

Thanks for the tip… looks like it works. With PhotoLab running and pointed to the folder in question, I can rename, delete etc outside of PhotoLab without creating a big mess. And for those occasions when I inevitably forget to open PhotoLab first, I can always delete the database. Nice to have a multiple workarounds in the back pocket.

#19

This doesn’t work if you rename in the way I described in my first post (when some filenames get reused).

I tried this one before as a workaround and from what I can tell, it works. I can rename the way I described in my first post as long as I also change the folder name. I assume that changing the folder name makes the database think all the images inside are new, even if some of the filenames aren’t.

#20

Well he is on windows. So he already loses history. Only issue is project membership.

I have renamed files outside of DXO many times. Rename the sidecars too and you should be okay. But yes project membership would be lost.

It’s bizarre some people still argue project membership doesn’t belong in a sidecar. SMH.

If you must retain project membership you MUST rename inside DXO. Otherwise you must close DXO and rename raw and sidecars together. Then relaunch DXO. In my experience even if you don’t delete the database you’ll be fine. Project membership will be lost anyway but otherwise you should be good.