Notes about "Modifiers" in the digiKam rename tool

Some users have asked me what modifiers are. They don't seem to know this concept in a renaming tool and are a little bit confused by it.
I will try to explain what the modifiers do and why I implemented the renaming tool in such a way.
Modifiers in digiKam rename tool

Update: Error Handling

Error Handling in Rename tool
Wrongly placed modifiers are highlighted now, so you can easily see if you made a mistake. A modifier is invalid when it is not added directly behind an option or an option-modifier pair.

Why Modifiers?

As mentioned in an earlier article, renaming in digiKam was not quite powerful, so I started to implement this new widget. I didn't want to have a full-blown
dialog for this, because it should be embedded in many places like in the MainUI, the importer and the BatchQueueManager. The concept of entering a template
string for renaming should already be known to users from tools such as KRename and similar batch renaming applications.

I tested some batch renamer tools and most of them seem to allow modifications only for the original filename, but not for all the other options they provide for renaming.
I never understood this limitation. What if I add the directory name and it is all uppercase, but I want it to be lowercase, to match the look of the overall new filename?
There doesn't seem to be a way to do this.
I know Metamorphose2 seems to do have something like modifiers, too, but for me the GUI is way too complex.
Edit: KRename seems to have modifier for all their options, too.

So I started my own tool and added keywords, that can be applied to every renaming option currently available. I'm going to explain the modifiers a little bit in the next section,
to show how they can be used.


Case Modifiers

Case modifiers change the case of a renaming option. Currently there are three modifiers available: Lower, Upper and FirstLetterUpper.
In the future these modifiers might be controllable with range parameters, so that you can, for example, have the first three characters of a renaming option in uppercase and leave the rest as is.


This modifier allows to convert a renaming option to lowercase characters.



This modifier allows to convert a renaming option to uppercase characters.


This modifier allows to convert each word in a renaming option to start with an uppercase character.




This modifier removes leading, trailing and extra whitespace from a renaming option. As you can see in the example screenshot, I added some whitespace to the replace modifier, that is removed again by the TrimmedModifier.



This modifier makes renaming options unique, avoiding name collisions. For example if you use the pattern shown in the screenshot, it is likely to have duplicate names.
The rename tool wouldn't let you process these files and mark colliding names in red. The UniqueModifier can help to avoid this. As you can see in the example, it adds a suffix number
to each [date:hhmmss] parse result when the value has already been used before.



The DefaultModifier can be used to set some value for options that don't return a string for some specific images. This can most likely happen with the camera or metadata renaming option.
To avoid a gap in the filename, you can set a default value, that is inserted in this case.
See the following screenshot:


Let's assume that some of these images where scanned in, so they have no camera name. We set the default value to "Scanner" in this case, and fill in the gaps.


This modifier replaces text in a renaming option, you can use regular expressions for more advanced pattern matching.

ReplaceModifier replaceModifier_regexp.png


This modifier only displays a given range of a renaming option.


Plans for the future

As you have seen in the screenshots, modifiers can be chained together. In the future I plan to add grouping, so that you can enclose renaming options and apply modifiers on each of them in one go, for example:


or similar. I'm not yet sure how to do it, but this could be one way.

why not regular expresions

And what about regular expressions in this rename field? Andi, have you thought about it? This is some 'standard', I know quite complicated for not experienced user, some geek stuff, but it will be nice to have it here. Regards,

Yes, I thought about RegExp,

Yes, I thought about RegExp, but unfortunately we have a feature freeze now.
I guess you mean the "ReplaceModifier"? Right now I can not think of another place where to use them.

Regular expressions can be

Regular expressions can be used in current SVN...

Unique modifier

Modifiers are very nice. Now the renaming is quite much more powerful. I hope to see option to put metadata fields in the name soon too.

I was just renaming some batch of files and wanted to employ unique modifier isntead of standard counter (####). I like the idea, because I always get the number of photographs that I took at one day. My idea was like this: something-[date:yyMMdd]{unique}.ext

Though I realized that using this pattern will produce confusing results, when images will be sorted by name - first image - which is without unique modifier - will appear last and just the second image will appear as first. The alphabetical sorting can result to something like this (on some systems):


I suggest that we can set minimum number of digits for unique modifier. So we get something like this:



I believe this will work on all systems.

To have the "Metadata"

To have the "Metadata" option, you need the latest libkexiv2, compiled from SVN (or shipped with KDE 4.4).

We have a feature / string freeze now so I only can add this option without users noticing it.
I guess I would simply use a syntax like that:

{unique:n}, where 'n' is the digits count.

I can add this in SVN, but you will not see it in the tooltip, nor in a config dialog, because the string freeze doesn't allow such changes now.

I added the parameter to

I added the parameter to current SVN, but you can not see it in the tooltip or somewhere else, due to the string freeze.
But at least it is there :D

I also thought about setting

I also thought about setting a minimal digits count of 4, but then again some users don't like this.
I kept the default to 1 by now, if you want to use more digits you can call the modifier like:

But maybe I will still go with 4 digits as the default... ;-) Don't know yet.

Thank you very much! I'm

Thank you very much! I'm impressed that my wish is fulfilled so immediately! Kudos to you!

I think having 4 digits by default is not that good. There are uses where the current default behaviour will do very well. I mean the cases where you don't need naming to follow time sequence, just you need to assure uniqueness.

Also I can imagine situation where 4 digits are not enough, and at this case unique modifier won't do what is expected to do - to assure uniqueness...

I would also suggest option to have something like {unique:auto} which will automatically create as many digits as is needed to make all files unique. (If there are 99 files with same name it will put 2 digits, if there is 100 it will put 3 digits etc.) I believe that would be useful quite universally.

Yes I thought of that, too.

Yes I thought of that, too. Right now it is not possible with current structure, and due to the feature freeze I can not change this now.
Please post wishes on bugzilla instead in the future, I don't receive notifications from our website anymore (don't know why) and need to look manually every time if new comments appeared (which I don't do often).