Feature #8507

Please add file rename functionality

Added by databeaver - over 7 years ago. Updated 4 months ago.

Target version:
Start date:
Due date:
% Done:


Affected Version:
git master branch
hardware architecture:


My workflow with photos is roughly as follows:

1. Get shots from camera
2. Prune any obvious failed shots (shaken camera, out of focus)
3. Compare shots of the same subject, selecting the best ones to keep
4. Go through all the shots, applying filters
5. Rename files according to date, serial number within that date and a short description
6. Export images for whatever purpose I need them for

Darktable can do everything but step 5. Currently I'm using a Python script to do the date/serial renaming and Geeqie to add descriptions. This works, but it requires me to reimport the files in darktable as the filenames change.

A hypothetical rename tool in darktable should have a configurable date/serial format and be able to automatically create per-day serials. The description should preferably be stored with the file metadata so it can easily be applied again if I decide to delete a shot late in the workflow and need to renumber the files. There should be a keyboard-only UI for entering descriptions (i.e. shortcuts for "next image" and "enter description") to avoid having to move my hands off the keyboard.


#1 Updated by Simon Spannagel almost 7 years ago


you can create a preset for the export plugin featuring your rename desires - this will at least name the exported jpegs to your needs. darktable does and will not alter the RAW files for the data's sake I think.

Does that work for you?

#2 Updated by databeaver - almost 7 years ago

Unfortunately, that's not an adequate solution for me. I specifically want to have the RAW files renamed. Renaming a file does not alter its contents, so this should not be in conflict with the policy of not altering the data.

#3 Updated by Tobias Ellinghaus over 6 years ago

  • Category changed from General to Lighttable
  • Status changed from New to Triaged
  • Target version changed from --- to Future
  • % Done changed from 0 to 20

We already allow to copy/move images to different directories, renaming shouldn't be hard and fit dt's principles.

#4 Updated by Tony Teoh Melkild almost 6 years ago

Tobias Ellinghaus wrote:

We already allow to copy/move images to different directories, renaming shouldn't be hard and fit dt's principles.

Sounds good. Renaming based on EXIF information is a must-have for me. My typical workflow:
- Import
- Rename all images with <my name prefix>-<event/location name>_year-month-day_time

#5 Updated by Tony Teoh Melkild almost 6 years ago

And also, it needs to rename the accompanying XMP files ;-)

#6 Updated by bruno binet over 3 years ago

I'm also interested by this renaming feature (to use it in a lua script): what is its status 2 years later?

Also, what happen if I move an image with darktable.database.move_image to a destination path where an image of the same name exists? Is it overwritten?

#7 Updated by bruno binet over 3 years ago

I've just seen that the destination file won't be overwritten, and the move is aborted:

In this case, it would be great to be able to set a new name when moving an image (or have another API method to rename an image) so that we can move files around.

#8 Updated by Karsten Salewski about 3 years ago

Hi Guys,

this seems to be a fairly old feature request. However, I want to second the author. I have pretty much the same workflow. Today I have to perform the renaming task with krename and import the renamed files to datable. Additionally I have to purge the old files, because they don't exist anymore to darktable after they've been renamed.
Pretty complicated for my taste.

Would be great, if this feature could make it on the shortlist ;-)

Best regards,


#9 Updated by Kael Shipman over 1 year ago

Hey all,

I've also been wanting this feature, and have been wanting to get my feet wet in Darktable Development. I'm going to try to take it on, but am pretty busy myself, so am setting a long deadline for it (like October 2017).

Here's my proposal:

We should handle this by changing the "move" button under "selected images" to "move/rename". When this button is clicked, instead of popping up an FS directory finder dialog, it should pop up a dialog that provides you the same path input field that the "export selected" section offers, i.e., a text input field that accepts a number of $(variables), plus a button that pops up the FS directory finder dialog.

This will allow us to reuse the code for the "export selected" section, and will also allow us to use the powerful EXIF variable substitution features built into that section.

The difference, however, will be that it will NOT export or copy the files it's operating on. Instead, it will rename them, including all associated XMP files.

If anyone sees any issues with this approach, please let me know.


#10 Updated by Kael Shipman over 1 year ago

Ok all, I've finally started poking around on this. It's gonna take me longer than I had anticipated to come up to speed, but I'm optimistic. If anyone wants to take a peek at what I'm doing or offer suggestions, I'm working in a branch on my own fork of the repo at

Warning, though: I don't think I'll actually be making any commits for at least the next few weeks. Lots to figure out first....

#11 Updated by Federico Bruni about 1 year ago

I've stumbled again on this.
Just for the records, the rename functionality is particularly useful when you want to rename some images you've already developed in darktable and you want to preserve the XMP file with all that information.

The dumb and dirty solution (which works with few images) is:

- remove images from darktable database
- rename image and XMP file in your file manager
- update the `xmpMM:DerivedFrom="NAME.EXT"` tag in the XMP file
- import again the images with a new name

I used a python script posted on the user list in the past, but I cannot find it anymore.

I look forward to Kael's work!

#12 Updated by Tobias Ellinghaus about 1 year ago

  • Affected Version set to git master branch
  • System set to all
  • bitness set to 64-bit

No need to edit the XMP files, darktable never reads that field. It's just there for you and to have the info in exported JPEGs.

#13 Updated by Kael Shipman about 1 year ago

Sorry for the delays all. I remain optimistic about doing this, but I've hardly been able to so much as breathe outside of work for the last 2 months! It's been a crazy fall.... Anyway, I'll understand if someone slides in and gets it done first. Otherwise, I'll keep it on my todo list for "someday soon".

#14 Updated by Rui Carmo 5 months ago

I'd like to chime in on this. I'd love to be able to batch rename my photos to a format like YYYYMMDDHHMMSS... (plus a letter for same second photos).

Have to resort to external scripts (and am looking into Lua), but it would be nice to have one less thing to fiddle with.

#15 Updated by Kael Shipman 5 months ago

Thanks for waking me up! I've been doing all kinds of other stuff and had completely stopped thinking about this, but I started digging in again tonight. I've got a path forward, but I'm such a C noob that it'll probably still take a lot of time and back-and-forth. If anyone wants to mentor me a little (part of my research into this has been studying the source code for mv from coreutils, but I really don't know if that's the best model here....) I would certainly appreciate the opportunity to ask lots of potentially annoying beginner questions.

Otherwise, I'll be on #darktable IRC this weekend as I try to hack a rough first draft of the functionality into place so I can submit a work-in-progress PR and have the DT people guide me.

(P.s., I just found the dt_variables_expand function, which is really what I was talking about when I mentioned "share code from export lib" above.)

#16 Updated by Kael Shipman 4 months ago

Update: I've learned a lot about C in the last week! I'm feeling comfortable with this now, and have gotten the code to the point where I can run it for basic testing, but I've gotten hung up on an error when I try to use the dt_image_full_path function (it says sqlite3 error: ... out of memory, though I can't figure out why, since I'm calling dt_image_full_path in exactly the same way as other functions in dt call it).

If anyone wants to see my work (in progress), look here: I would very much appreciate some pointers about why I'm getting the error I mentioned. When I get that cleared up, it shouldn't take me too much longer to get the rest of the functionality in place.

#17 Updated by Kael Shipman 4 months ago

Update: The plumbing is coming along. I've now got a function that generates the correct target path (which is basically a glorified pass-through to underlying dt functionality), and I've got it mostly worked into the right order. I just need to actually execute the move from current_path to targ_path, dragging along all sidecar files. Since that functionality was already written in the current dt_image_move function, I should be able to complete it next week with a modified copy/paste.

One question for the maintainers, though: Someone (Houz, maybe?) had originally told me to make this it's own module in src/common. However, it makes a lot more sense to me to replace the dt_image_move function in src/common/image.c. Does anyone mind if I steal that space? The functionality I'm writing would presumably replace the functionality provided by the current function, though the function signature would change.

What I'd like to do is replace the function with my new function, remove the move button in the image library, and (with lots of help from other devs) implement the new field in the UI, such that it calls my new function. Just not sure if maybe it's necessary to leave the old function around as deprecated or something....

Also available in: Atom PDF