Poll: Did you ever expect a version relation to propagate renames?

[lbo]

Hi IMatch users,

did you ever expect that a version relation propagates master renames to version files?

This means, a master rename from "IMG_4711.raw" to "foobar_4711.raw" would cause the version file IMG_4711.jpg to be renamed to foobar_4711.jpg

Currently, you need a buddy relation in addition to the version relation to propagate such a rename.

The help for Buddy Files does not necessarily suggest this use: "A buddy file (sometimes also referred to as sidecar file or sidekick file) is a file which is related to a master file and contains some additional information or data. Typical uses for using buddy files are: [...] previews for RAW files, [...] voice annotations for an image, settings files maintained by some RAW processors for each RAW file".

Using a buddy relation just to propagate the version renames didn't seem to be the intended use to me initially.

I expected the version relation to (optionally?) propagate a master rename to the version.

But it could be that my idea was a little out of the norm, therefore I'm curious what other users think about.

[JohnZeman]

Since my final image file names are all based upon the date/time the image was taken, it's a non issue for me.

The standard renamer works just fine for my needs with masters, buddy files, and versions.

[Carlo Didier]

Once a file is ingested in iMatch and has gotten its name according to my naming scheme, I never ever rename any file, be it master, buddy or version. It would break my workflow and has never been needed.
So this is also a non-issue for me.

[sinus]

With the standard renamer and my workflow I have fully control over my naming scheme.
Hence this is also a non-issue for me.

[Mees Dekker]

Same here. Issue raised by lbo si not a problem for me.

However: a bit more clarifying in the help may be useful.

[Jingo]

same as others.. my initial files are renamed at the start of the workflow and never touched moving forward.  Sounds like a good idea for an APP!

[lbo]

Thanks to all for your comments.

As far as I see, all of you rename before creating versions, never afterwards.

Thus, the behavior of the version relation is irrelevant for you, since no versions exist at all when renaming.

Sounds like a good idea for an APP!

There is no need to add or change anything since IMatch provides tools to propagate the rename (buddy relation).

@Mees Dekker: I didn't intend my post to describe an "issue". I was just curious about other user's workflow and expectations, and (as I wrote in the OP) I already considered that my method deviates from the average.

I often need to create jpegs from the raw files quickly, before I have time to set descriptive names. Therefore I rename stacks (raw + version) routinely.

[jch2103]

As far as I see, all of you rename before creating versions, never afterwards.

Thus, the behavior of the version relation is irrelevant for you, since no versions exist at all when renaming.

Well, a few of us have good intentions about renaming files on initial ingest, and then sometimes get ahead of ourselves...

So sometimes I need to rename originals and versions, which of course is awkward at best. I've figured out ways (external programs) to do that after the fact when needed.

But the better long-term solution is to stick to my formal workflow in real life!

[lbo]

So sometimes I need to rename originals and versions, which of course is awkward at best. I've figured out ways (external programs) to do that after the fact when needed.

IMatch does support this without the need for external programs but needs a buddy relation in addition to the version relation to propagate the renames.

But the better long-term solution is to stick to my formal workflow in real life!

IMO there is nothing wrong with a "late rename" workflow. Sometines I work with raw files deliberately underexposed to enable high dynamic range (modern "ISO invariant" sensors are nice!). Working with versions as visual proxies is much easier than with the dark raw files.

[sinus]

I often need to create jpegs from the raw files quickly, before I have time to set descriptive names.

I understand this.
A long time ago I had this issue too, but this behaviour (create jpgs before naming raws) gave me afterwords a lot to do and I liked also not to work with names like "IMG_20190713_230227" or "_DSC_8918", gave me a bad feeling.

Then I created simply a good renaming-set and now, even if I have to naming 500 images (what is seldom in my case, I have usually about 100 images), this takes 2 or 3 minutes (including backup each file with help of the renamer!).

Hence if I have 100 images and have to send them quickly to a newspaper, the renaming takes for sure not longer than 2 minutes.
And even this, I think, is not that long (sometimes it takes longer to get a cup of coffee  )

But of course, your workflow is another and you work maybe with a lot more of images.

[ubacher]

Yes, sometimes I like to rename my files after I have created versions. I also have a Samsung smartphone which produces
dng and jpg files together. For these my renamer app takes care of renaming both the master and the version.

For manually renaming a Master/Version set I did write myself an app so I have to enter the name only once.

(I do not like to use buddy files because I often only delete the master and keep the version)

[lbo]

Then I created simply a good renaming-set and now, even if I have to naming 500 images [...], this takes 2 or 3 minutes

Does this renaming-set impose manual entry of descriptive names or is it mostly automatic?

In my case, one session can yield also 500 images with dozens of different objects shown, not ordered but mixed in the timeline. Then I need to research what is shown at all and find the right descriptive name for it. That's the most time consuming part of my work.

[lbo]

For manually renaming a Master/Version set I did write myself an app so I have to enter the name only once.

how does this app work (e.g. compared to the IMatch renamer)?

[sinus]

Then I created simply a good renaming-set and now, even if I have to naming 500 images [...], this takes 2 or 3 minutes

Does this renaming-set impose manual entry of descriptive names or is it mostly automatic?

In my case, one session can yield also 500 images with dozens of different objects shown, not ordered but mixed in the timeline. Then I need to research what is shown at all and find the right descriptive name for it. That's the most time consuming part of my work.

Uh, in this case I guess, you are much more precise then me with your file-naming.
I have 3 boxes to fill out, but they appears automatically and they are filled in almost no-time.

Say, I was on an event, like a party or football-match or wedding.

I select all of these images, say 300 image.
Then I click on the favourite "renamer"

A box appears (see attachemt), usually I hit very quickly return, because it it mostly the same.
A second box appears, I have to choose the client. Also quickly done.
Then the last box appears, where I use the moste time, I would say 10 seconds.
It is a short description of the event like

wedding Simson
Bayern-Cosmos
animalfarm huber

and so on.
I have very good experience with such short-names in my files. Quickly to search and I can see also outside of IMatch, only by the name, what it is.
All these are events for me.
If I make versions, they are only different at the end of a file. The file, what I renamed for the attachement here (I left the text Beschreibung, where I usually write of course something), has not the name:

20150925-1422-374621-s-kun-beschreibung_a.nef

If I create versons, it would add at the end (mostly in Photoshop) something and the jpg would be
20150925-1422-374621-s-kun-beschreibung_a_v1.jpg

Of course I add gps, headline and so on.
I propagate all raws, hence the jpgs have the same attributs.

At the end I stack ALL image from one event (a wedding) and have one image to represent all 300 images.
This works fine.

If I understand you correct, you do name your files much more precise and detailled.
If I am not wrong, this would mean, if for example the bride is on some images, this would be written in the filename? and image from the groom would have another description?!
Or did I misunderstood this?

Means, in my case all image have the same descriptions (of coures different numbers), but if there is a building like "Tour Eiffel" or a mountain "Matterhorn", then of course this is in the metadata in the headline or/and description.

I think, we have here a lot of different workflows.

[lbo]

Uh, in this case I guess, you are much more precise then me with your file-naming.

yup, for example MUC_Pasing_W, MUC_Friedenheimer, MUC_Hirschgarten, MUC_Stachus and so on, and same-named images are not consecutive, so sorting them is a major part of my work. The descriptive file names allow me to sort the images by name and therefore by topic.

It's stock photography, so I shoot "everything" looking interesting.

The descriptive naming has also benefits in later stages.

If I create versons, it would add at the end (mostly in Photoshop) something and the jpg would be
20150925-1422-374621-s-kun-beschreibung_a_v1.jpg

I also add descriptive appendices to versions. Did you see my feature request Enable renamer to process buddy files?

Even if you don't use buddy relations and/or seldom change the name of a version afterwards, you might like the idea of a more liberal renamer.

If I am not wrong, this would mean, if for example the bride is on some images, this would be written in the filename? and image from the groom would have another description?!

correct (see above).

I think, we have here a lot of different workflows.

that was to be expected, and part of the reason I started this thread.

It's interesting for me to see other people's workflows, thanks for sharing yours.

[Carlo Didier]

... Then I need to research what is shown at all and find the right descriptive name for it. That's the most time consuming part of my work...

That's why I use a simple unique numbering of the files. Everything else is metadata and stored as such in the files and/or iMatch categories, not the filenames.

[lbo]

... Then I need to research what is shown at all and find the right descriptive name for it. That's the most time consuming part of my work...

That's why I use a simple unique numbering of the files. Everything else is metadata and stored as such in the files and/or iMatch categories, not the filenames.

The main effort is sorting and assigning a description. This part of the work needs to be done anyway. Setting the filename (also "metadata") is insignificant work compared to this.

A descriptive filename has several advantages in my remaining workflow and it's said that descriptive URLs have a SEO benefit.

[Carlo Didier]

Sounds perfectly reasonable. Whatever works best for your workflow.

[sinus]

I use filenames with a rather complicated scheme. Above all, I also use a very short descriptive text for the filename.
In the past it has been shown that many users find this unnecessary.
Well, it worked well and even for backups, or wherever without DAM, I can see what kind of image it is by name, I like it.

Such a name looks like this:
20190830-1429-374610-s-coo-ziegenkaese_m_.nef
and a version
20190830-1429-374610-s-coo-ziegenkaese_m_v1_f.jpg

But of course I don't want to impose such a picture name on my customers.
So I have different renamer templates to create other names based on this name.
It's fast and easy.

Often I use such a name:
sinus-74610.jpg or even
s-4610.jpg or
Diane-4610.jpg

With this number I can quickly find the original due to the unique number (374610). If I take only a thousand number (4610), then there are not many pictures in the archive with this number and the correct picture is found fast.

Because I don't necessarily want to impose 374610 on the customer, so I shorten them.

But now there are customers who give their own filenmamen.
These can be very complicated names like e.g.
4.863a.3554_PreSpezRari_Chevr_Frischk_Nat_100gFE.jpg
08742194-diana-muller.jpg

That's what I'm solving:
I have a metadata field in which I write such desired filenames, e.g.
4.863.554_ProSpeciaRara_Chevr_Fresh_Nat_100gFE

Then I made a Renamer preset that simply replaces this text with my filename (or parts of it).
It's quick and easy.
Works with raws and with versions, because they are different endings.
If there are several variants, I simply insert clear endings at the end in the metadata field, such as
4.863.554_ProSpeciaRara_Chevr_Frischk_Nat_100gFE-variant1
4.863.554_ProSpeciaRara_Chevr_Frischk_Nat_100gFE-variant2

I can make these name changes with copies (and then delete them) or I can simply restore the original name with another Renamer-Presest.

And the best part is, because I have these names in the Metas anyway, I can also search for them.
Means, if a client asks for something with "...PreSepzRari", well, easy to find.

That means, if I had an even more detailed naming scheme like lbo, and if I was in a hurry, I could quickly create versions and rename the filenames afterwards by using the headline, the location or another metadata field as base for my filenames.

This should work fine, even with versions. But I didn't test it, only theoretically.

This simply times my considerations in addition.
We certainly have 38124 different workflows here below the users.