Suggestion: multirename - allow [c] to start from specified value

Discussion and questions - donor version.
Post Reply
Message
Author
dsperber
Posts: 221
Joined: 28.03.2010, 01:35

Suggestion: multirename - allow [c] to start from specified value

#1 Post by dsperber » 10.06.2020, 13:54

I commonly do a multi-rename of new photos, which are actually of food I've cooked. I use Photoshop to perform a mass image processing "script" on a sequence of original photos taken with my phone, where the originals are large dimension (4032x2268) 16x9. I'm using Photoshop to produce a new corresponding set reduced in size to high-quality 1600x900 dimension (more suitable for sharing by email than the very large originals). Photoshop names the new reductions identically to the originals, and places them in a folder by itself.

The JPG image files produced by the phone camera are named with date_time (i.e. YYYYMMDD_HHMMSS), and the same names are produced by Photoshop for all the reductions placed into the separate folder. I then use FCXE multi-rename to rename the newly created reductions using English words to describe the dish, appended using a suffix of "[c]" from the FCXE dropdown pattern list. So the photos end up with a prefix of the name of the dish and a suffix of a sequential number of 0001, 0002, etc.

This is all perfect.

But if I make that same dish again, and take more pictures of it, and again use Photoshop to mass-reduce all of them to 1600x900 and again want to use FCXE to perform the very same multi-rename on the new set of reduction JPG's, what I really want is to start the [c] sequence number for the new set to be the next available number following whatever is the last current sequence number of the current collection of files with the same prefix. So, for example, if I currently have 0007 as the last sequence number for "linguini-vongole" (i.e. "linguini-vongole_0007"), I really do want the new batch of multi-renamed files to begin with "linguini-vongole_0008" rather than the "linguini-vongole_0001" it is always currently going to start with when I use the existing [c] parameter in multi-rename.

As things currently work, I have no control over the starting value for [c] and it always begins with 0001. This would then require me to follow the multi-rename with a series of individual manual renames (F2), changing all the files just multi-renamed by FCXE to have the proper sequence number suffix, which will result in their getting correctly "appended" as new photos in the set of existing files for the same dish, i.e. with the same prefix.

So, what I'd like to request is a way to specify the starting value for [c] in a multi-rename, to be either 0001 by default or whatever I manually specify instead. In my example it would be 0008 for the new set of photos for my "linguini-vongole_nnnn.jpg" set of files.

I don't care if a different parameter from [c] is invented anew to allow entry of the initial starting sequence number and leave [c] just as it is today, or if [c] is enhanced to allow a manually entered starting sequence number. But some way, it would really be convenient if I could get [c] to start at the nnnn sequence number of my choosing, whatever nnnn is.


Another more complex way of accomplishing all of this in one fell swoop is to actually invent another "pattern" which is defined by pointing to an existing file name, which is assumed to be of the form prefix+suffix where the suffix is assumed to be nnnn, i.e. [c] from a previous multi-rename or however it came to be. And then the entire file named pointed to is treated as the "pattern" field, totally absorbed with the implication that the first newly renamed file will have exactly the same "pattern" with the suffix "nnnn" automatically incremented by 0001 from whatever it currently is.

So in my example, using the newly invented "pattern" ID I would also point to the existing file "linguini-vongole_0007.jpg". And this would 100% imply that I want all of the newly selected files to be multi-renamed with exactly the same file name layout, and that the implied suffix is really "0007 + 0001", i.e. a new starting initial sequence number suffix of 0008. This would be exactly what I want, namely the entire new set of reduction photos appended by renaming into an "existing set" family of files with the same prefix. So the first newly renamed file in the new group gets multi-renamed starting with "linguini-vongole_0008.jpg", etc. simply by pointing to a current "last in existing set" file whose name is "linguini-vongole_0007.jpg".

So in this alternative (and more sophisticated) approach I wouldn't have to manually provide a starting value of 0008 for [c] at all. I would simply point to an existing file of whatever name it has, which is supposed to have as its suffix a sequence number of the form nnnn (like [c] would create). And the ENTIRE file name would be used as a "pattern" for the multi-rename, with the existing nnnn suffix used to determine the new [c] suffix as 0001 higher than the existing nnnn.

Just thinking out loud. Obviously this second method is much more complex than just allowing for a manually specified initial starting nnnn value for [c]. But it would do everything all at once, automatically defining both prefix and suffix (i.e. [c] of the "pattern", with the next [c] being 0001 higher than the existing nnnn in the identified file name.

Timon
Posts: 729
Joined: 13.09.2012, 08:51

Re: Suggestion: multirename - allow [c] to start from specified value

#2 Post by Timon » 10.06.2020, 19:51

You can set [c] starting sequence number any you need:

Multi rename -> Counter ->
Start at:
Step by:
Digits:
Reset per folder

dsperber
Posts: 221
Joined: 28.03.2010, 01:35

Re: Suggestion: multirename - allow [c] to start from specified value

#3 Post by dsperber » 10.06.2020, 22:33

Well, egg on face. I never noticed those "counter" fields before you mentioned it. Or perhaps I did and somehow never mentally connected this group of "counter" parameters with controlling [c], which is of course on its face now embarrassing.

Yes, this is exactly what I was looking for! Here all along.

I retract my "suggestion" for a new feature.

Case closed. Many thanks.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 42 guests