Anybody use/have example of: *prefix* or *file location* for versions and more?

[MrPete]

I've done some searching and found little by way of information or examples of either of these use cases:

1) My sweetie renames all files with a *prefix* to name the event/location for a group of photos.

   Examples DBG-CO_XYZ_1234.NEF is Denver Botanic Garden CO; ClearSpringRanch-CO_XYZ_1234.NEF

And then she goes further sometimes with a pre-prefix. Example:
   09-01 Balloon Glow_ColoSpgs-CO_XYZ_1234.NEF
    - To be published on Instagram 09/01, title Balloon Glow, location Colo Spgs CO

AFAIK these would all be versions of the original.

I've not found any examples of version regex that handle prefixes, although I think I read that Mario himself uses prefixes for some purposes?

(AND: are there examples // is it easy/hard -- to extract further data from a filename and turn it into metadata or category or whatever?)

(AND: has anyone scripted things like auto-publish photos to social media? LOL. That's NOT an urgent question at all! Just curious while I'm looking at this )

2) Folder-based insights.
I am just coming up to speed on all of this in a serious way. All of the examples I've seen for versioning seem to assume that versions and stack priority are based on file extensions. In my case, which folder a photo is in can say a lot:
   - not yet posted, vs
   - already used
   - vs ready to share
etc...

  I almost certainly missed this in the tutorial info... but am wondering if there are examples
   - of setting stack priority/sequence based on folder/subfolder location?
   - of auto-tagging in some way based on folder/subfolder location?

(It is FINE to tell me the equivalent of RTFM -- Pete, you will see that info when you get there )

THANKS!

[Mario]

I've not found any examples of version regex that handle prefixes, although I think I read that Mario himself uses prefixes for some purposes?

Not really. I keep my file names simple, like YYYY-MM-DD-sequential number. Simple is better.
Information like " Denver Botanic Garden CO; ClearSpringRanch" really belongs in metadata, not in file names.

Adding all kinds of random data to file names will make it much harder for IMatch to automatically grab versions based on file names and regular expressions. I'd never try such a thing and probably other users neither. Which explains why you don't find examples.

The {name} pattern can be used in matching. It contains the name of the master file (except for replacements done via //). This is what you have to work with. If you prepend stuff to the front of the file name in versions, your regular expression must consider that and add stuff in front of {name} in the mask.

I know that users did all kinds of crazy things with file names back in the day, trying to somehow convey information for software like Windows Explorer, which could not use metadata.
Windows Explorer added support for metadata display more than a decade ago, and users with overly complex or 'wordy' file names usually regret it at some point in time and have to put in the work to convert the file names into something more standard.

(AND: are there examples // is it easy/hard -- to extract further data from a filename and turn it into metadata or category or whatever?)

Metadata Template utilizing the {File.Name} variable and some function trickery like substr to extract various parts of the file name and put it somewhere? See Formatting Functions for a list of function IMatch offers. If the terms/words you have added to the file name vary in length, this will be harder to do. You can use find or findreverse to find separators you have used and use that to feed in position and length into substr. Always tricky, but at least not impossible thanks to the power of IMatch variables.

2) Folder-based insights.

File relations are based on file names. IMatch allows you to look for versions in the same folder as the master, below that folder, in specific folders or, worst-case scenario, performance-wise, in all folders. Not recommended.

In my case, which folder a photo is in can say a lot:
  - not yet posted, vs
  - already used
  - vs ready to share

If you expect specific versions in specific folders, you can setup multiple file relation rules (for the same masters), making each search for versions in a specific folder. You can use Folder Patterns and literal text to construct the names of the folders to look into for specific versions. Tricky but probably solvable.

Again, information like this should not be encoded in folder names. It should go in metadata or maybe IMatch categories.
Things like this are the main purpose of a DAM:

If you are currently transitioning from a handmade folder-based organization to IMatch: Consider using Metadata Templates that uses e.g. the {File.Folder} variable to transfer the folder name into a keyword or XMP label or something.
XMP labels have been designed to carry the workflow state of files, like "new", "processed", "waiting to be posted", "posted". Or you can use workflow categories like I've described them in a recent blog post on my web site.

Or create a data-driven category based on this variable. This produces child categories like "not yet posted" or "already used" and makes this information easily accessible and usable in IMatch. Moving files around in the file system in order to reflect their current "state" is something you do when you have no DAM.

[MrPete]

Thank you, Mario!

YES, that's exactly correct: she's been doing all of that because no iMatch. I need to get this set up and help her transition. That's really the point of this.

To place the workflow aspect in iMatch context, consider that she has (manually) created the equivalent of specific Batch Processor output folders for certain workflows.

But no iMatch. Thus, we need to import the info about those JPG exports into iMatch, and mark those images as versions for proper stacking etc.

It's as if I'm using Batch Processor with settings for:

• A specific hard-coded folder
• Filenames based on a metadata pattern (exactly as described in the Batch Processor help: "you can use variables to produce output file names from the metadata stored in the file...")

But in this case, instead of having these settings drive Batch Processor export, I need to import those images and properly integrate them into the iMatch database. 

Isn't this close to the DAM-based use case, where exported images are also maintained in the iMatch database?

Even though it isn't discussed in the help, it would seem that there's a need to link import and export to some extent:

• Versioning setup needs regex that can properly recognize exported images (and stacking setup as well?)
• Batch Processor export folders should be recognized as a location for related images.

Am I still overthinking this?

[Mario]

Versioning setup needs regex that can properly recognize exported images (and stacking setup as well?)

Most versions are exported from somewhere.
Most users produce them for instance in a RAW Processor, Photoshop, Office, video editing software or similar. Same thing, really.

Your naming convention should be supportive to the file relations feature in IMatch and how it identifies masters and versions. Not making it extra hard by adding random text to the front and end of version file names.
Not even IMatch can handle all situations. And, from what I have read above, your use case and naming convention are quite special.

I've listed the tools and features you can use to make your file names more standard, without losing context and data.
Metadata Template(s) to extract important bits from the file/folder names and store as metadata. Then IMatch Renamer to produce a more standard naming convention that can easily be handled by file relations.

If all built-in features in IMatch prove to be unsuitable for your particular case, you can always write (or hire somebody to do it) a script that "understands" your file names, can extract the information you want, store it in metadata and finally rename the file.

The programming interfaces provided by IMWS in IMatch are very powerful and give you direct access to most things stored in your database, the file system and more. See https://www.photools.com/dev-center/doc/imatch/ for further info and the IMWS help embedded in IMatch (App Manager).
You can use Windows PowerShell or Python or Basic or c/C++/C# or any programming language that can deal with REST services as provided by IMWS.

Batch Processor export folders should be recognized as a location for related images.

This is how it works.
When you add the output folders the Batch Processor creates to your IMatch database, use a good naming convention for the folders and files (e.g., name the folders "deliverables" or "Facebook"). Use file names for the outputs which match the source/master file names or maybe add a prefix to indicate the type of version when you have more than one. This makes them easy to parse and link to masters.

A consistent naming convention allows you to handle all that with a single file relation rule that searches for versions in the "deliverables" folder under the folder containing the original.

Or maybe in "E:\data\deliverables\<name of folder containing the original files>", which is a folder hierarchy you let the BP create. If the master folder is named "2024-08-25" then the versions would be in "E:\data\deliverables\ 2024-08-25".  And this can be easily specified in the file relation using a folder pattern and a hard-coded E:\data\deliverables\ . Quite easy. There are examples in the help for this.

If your file naming conventions are fuzzy and words are added as prefixes and suffixes to the original and/or version file name, things will be more challenging. Regular Expressions can do a lot (which is why IMatch uses them), but certainly not everything.

[MrPete]

The original use case for import is unique to her situation. Not a surprise as the files are "pre iMatch"   . 

For the future, there will still be Batch Processing exports to a specific folder for later upload to Instagram or photo printing service etc.

I think the key here is that attributes needed for external processes (such as title or abbreviated location for Instagram posting) can be embedded in the filename using nicely defined field separation characters that are easily parsed.

I'm not too concerned anymore: I am confident I can create parsing rules for my wife's current and her one or two previous naming conventions -- even though she was working manually, she's been quite organized! With the power of iMatch, I suspect I can identify files based on the naming pattern she used... and thus discover any files that don't fit the pattern. Ought to simplify the import process quite a bit.

This will be a bit of effort, but oh so worth it

[thrinn]

Examples DBG-CO_XYZ_1234.NEF is Denver Botanic Garden CO; ClearSpringRanch-CO_XYZ_1234.NEF

And then she goes further sometimes with a pre-prefix. Example:
  09-01 Balloon Glow_ColoSpgs-CO_XYZ_1234.NEF
    - To be published on Instagram 09/01, title Balloon Glow, location Colo Spgs CO

If you really need prefixes and/or suffixes, you should make really sure that there is an easy rule to distinguish parts of the filename (prefix, actual filename, suffix). For example, if a prefix is always 3 characters long, it is quite simple to extract it with a RegExp. Alternatively, having a schema like "everything before the first dash is the prefix" would also make it possible to use a not-too-complicated RegExp.

But the two examples you provided are not very rule-friendly: Even as a human, I could not identify the "prefix" without your explanation. And having to use the word "sometimes" to describe a naming scheme is always a warning sign in my experience.

Personally, I use suffixes to distinguish between different versions of the same image:

Code Select Expand

2024-03-19-009.arw
2024-03-19-009.jpg
2024-03-19-009_C1.jpg
2024-03-19-009_AFP.jpg
The important thing is: The master (2024-03-19-009.arw) and its versions all share a common part of the filename (date plus a counter). This way, a RegExp can easily be used to identify which files belong together, and versioning works as expected.

There are other users (like sinus (Markus)) who also code meta information in the filename, resulting in quite long names. But still, he adheres very strictly to his scheme and has a clear structure which part of a filename means what. Using different variants of naming approaches in parallel makes version rules really complicated and difficult to understand.

[MrPete]

The patterns are actually quite simple:

• underscores separate prefix1_prefix2_mas_terN.*  (ie master name is XXX_NNNN)
• prefix 2 may have - and/or blanks
• prefix 1 has mm-dd then space then title

[Mario]

prefix 2 may have - and/or blanks

I'm sure you can figure out a variable with find and substr to break that up. "May have" always raises a warning for automatic processing, though.

[sinus]

Wow, Thorsten, you have a good memory!
And you are correct.

Users has a lot of different filenames-systems.
Here just for see it some filenanmes, what I use:

20240702-1030-474811-s-kun-zobrist_a.nef
20150506-1156-259036-s-kun-ergotherapie_m.nef
20150506-1156-259036-s-kun-ergotherapie_m_v1.jpg (version)
 
20130911-1945-211099-s-pri-fussball-rohr_m.nef
20080306-1038-090453-s-coo-apotheke_kern_a.nef
20000908-1714-012294-c-kun-ifw-hummel_o.jpg
19980912-1026-355423-c-pra-wanderung-matterhorn_o.jpg
15430606-1313-222222-c-vip-kopernikus_o.png
10500606-1313-019152-s-soz-maseltrangen_o.jpg

And like Thorsten wrotes, I try to have a clear structure, make changes easy.
At the front, date-time, then some interenal numbers, codes.
In the end I am free for short-text to remember and at the very end codes for masters, versions.
(btw, I have my versions in the same folder like the parent)

The date in front is very good for sorting, also in Explorer.
It is asthonishing for me, like I can very often remember, even without IMatch, simply in the windows-explorer, only with the short text, what this photo is (from what event). Sometimes I must look also at the date, that it is fully clear.

Means, for me, I can see (mostly) only with the name, what kind of pictures this is.
What have some advantages, if there is only the date without text.

There is only one disadvantage: the filenames tend to be long.

[MrPete]

prefix 2 may have - and/or blanks

I'm sure you can figure out a variable with find and substr to break that up. "May have" always raises a warning for automatic processing, though.

I do have regex's for all of that now, thanks. Working through more and more... quite the interesting process to integrate a significant existing collection into iMatch for my very-organized wife. (Me? Not so much  -- but then not nearly as many photos.)

[Mario]

Always a more or less elaborate project to upgrade to a DAM.