Versions for HDR and panoramas

[rolandgifford]

I'm reasonably sure that I now have a versioning rule which handles the bulk of my out of camera and processed photos as I would like.

HDRs and panoramas aren't handled as I would like and I wouldn't expect any automatic rule to handle them without risking breaking my more usual way of working. My hope was to allow the automatic versioning to run then break the automated versions for the selected photos merged into one and replace them with a manual version set. From my reading of the help I can't break an automated version set.

My rules are based on the file names matching exactly and I always have a matching pair (raw and jpg) for every photo I take so every file is part of an automatic version set. I could manually delete or rename the jpgs for HDR/PANO to remove these version sets but I would prefer some other solution.

Is my reading of the help correct that an automated version set can't be removed for selected pairs?

[Mario]

Is my reading of the help correct that an automated version set can't be removed for selected pairs?

When you setup a file version rule, it will be applied. That's how it works.
You cannot exclude individual files when they match the file name patterns you have created.

Either use a different naming convention for files you don't want to version, use different sub-folders for versions you don't want to be detected, use manual-only versioning. IMatch offers you many features to handle this.

[rolandgifford]

When you setup a file version rule, it will be applied. That's how it works.
You cannot exclude individual files when they match the file name patterns you have created.

Thanks, I had read the help correctly.

My current versioning rule is simple and relies on the name matching, nothing fancy.

Some sort of file renaming rule will probably be my best solution. Changing the names so they are all the same then appending a unique letter to each or something of that sort may be the simplest but that may break knowing which is an original jpg/raw pair (if that actually matters, I'm not sure that it does).

Then I could match on filename plus a single letter. As none of my other file names would have a letter at the end it wouldn't break that. I currently have file names which are <trip><datetime><uniqueness number where required> so some would have slightly the wrong time but that doesn't matter and all the same name would make it easier to see a set in Windows Explorer.

[Mario]

Try to use the simplest possible approach. IMHO.
For example, move the versions you don't want to become detected into a sub-folder not covered by our relation rule.

Creating some complex setup with file names, prefixes, postfixes, appending numbers etc. to file names etc. sounds like something that can easily break when you change your workflow or tool chain. Usually simple is best.

[rolandgifford]

Try to use the simplest possible approach. IMHO.
For example, move the versions you don't want to become detected into a sub-folder not covered by our relation rule.

Creating some complex setup with file names, prefixes, postfixes, appending numbers etc. to file names etc. sounds like something that can easily break when you change your workflow or tool chain. Usually simple is best.

I understand and mainly agree with what you say but having names which are the same for the set does have other potential benefits on it's own. I frequently have number suffixes to make names unique as I use burst shooting a lot.

Identifying the sets to move them to another folder followed by manually versioning sets in that folder is probably more work/risk than identifying the set and running a rename rule on the selected files. If I have a rule for renaming and a rule for versioning, the only thing that I can do wrong is select the wrong batch of files and therefore could be the simplest approach.

I'll have an experiment. I was mainly checking that my preferred solution (remove the automatic versioning and replace with manual versioning) wasn't available.

[rolandgifford]

Having thought some more I'm going to have to move them out of the way in some way because renamed files will still be versioned pairs unless I rename them differently which starts to make things way complicated.

More thinking required

[rolandgifford]

Try to use the simplest possible approach. IMHO.
For example, move the versions you don't want to become detected into a sub-folder not covered by our relation rule.

Can I exclude a particular folder name from relations rules? I can't see how to do that.

I'm thinking of having a sub-folder called Panorama for each trip to contain the base files for the merged photo. This folder will contain raw/jpg pairs which I don't want to be versioned automatically. I can not include it in the base folder rule by using folder name patterns but I can't see how to exclude it in its own right as a base folder.

[Mario]

Can I exclude a particular folder name from relations rules? I can't see how to do that.

Use the List of Folders mode and specify the folders you want to process?

[rolandgifford]

Can I exclude a particular folder name from relations rules? I can't see how to do that.

Use the List of Folders mode and specify the folders you want to process?

That covers part of the requirement and I would intend doing that so that when IMatch processes the base folder it only looks for versions in the processed sub-folder and not the panorama sub-folder. I can see that working well.

What it doesn't cover is when I'm looking at the panorama sub-folder itself (just looking, renaming, whatever) where IMatch will look for and find matching pairs as they are both in the current folder. Turning off automatic versioning will probably resolve this as I wouldn't look for version in this folder deliberately. I'm wondering if there is some way to protect myself from looking for versions in this folder accidentally. Once the pairs are versioned I can't then break the link, being able to do that would also solve my problem.

[Mario]

I'm not sure that I understand how you process your files.

I keep the masters in the "root" folder, and versions and deliverables, documentation etc. in sub-folders.
If or not a file becomes a version can be controlled via the name of the sub-folder and folder patterns (see my link above).

IMatch always looks for versions based on the folder it finds the master in. It looks in the same folder, all sub-folders 1 to n levels deep or only in sub-folders matching the naming schema you configure. I think is gives you plenty of options.

[rolandgifford]

I'm not sure that I understand how you process your files.

My camera produces a raw and jpg file for each photo. These go into a folder for the trip:

C:\trip1

These are then versioned into pairs so that labels etc are mirrored between the two

After removing rubbish/duplicates/etc I edit some using Affinity and place the edited files in a sub-folder called Affinity, same file names so I then have:

C:\Trip1
C:\Trip1\Affinity

Version Trip1 again with a named sub-folder of Affinity and I get sets of 4 for the edited photos.

For the vast majority of my photos this works well. However I take a small number of sets of photos to be joined into panoramas and sets for HDR editing where this process doesn't work because the names aren't the same.

I'm happy to move these photos out of C:\Trip1 and put them in a sub-folder so that I then have:

C:\Trip1
C:\Trip1\Affinity
C:\Trip1\Panorama
C:\Trip1\Panorama\Merged

With this the C:\Trip1 versioning works as I have said to look in the current folder and a sub-folder called Affinity, nowhere else.

I want to manually version files in C:\Trip1\Panorama but these are raw/jpg pairs and will be versioned by the same rule that updates Trip1 unless I turn automatic versioning off and only check for versions in the current folder when I request it.

This manual versioning request will probably work in the future. "Please version this folder" is what I'm used to. However, I am migrating from different DAM software and have about 200,000 photos spread across about 200 folders and doing those one folder at a time isn't a prospect that fills me with enthusiasm :-(

Ideally I want a folder called Affinity or Panorama or Merged to never be treated as a master. I'll work round that if I can't have it but it is sensible to ask.

[Mario]

I want to manually version files in C:\Trip1\Panorama

I suggest you use folder patterns to make IMatch search only in the Affinity folder for versions.

As for masters, IMatch will look in all folders for masters. If you don't want a file to be considered a master, you can do that via the file naming convention you use for masters (e.g. use a postfix like _pano) to differentiate between files you want to use as masters and others.

Or play with the Limit by Variables option. See if your pano masters have some unique metadata you can use to filter them out.

Your versioning requirements are unusually complex, but I'm sure with folder patterns, a good naming schema or Variables, you will be able to solve it. If not, you can always use manual versioning as a last resort.

[rolandgifford]

Your versioning requirements are unusually complex, but I'm sure with folder patterns, a good naming schema or Variables, you will be able to solve it. If not, you can always use manual versioning as a last resort.

They are and they aren't. Other people must take stitched together panoramas and HDR sets. I was hoping that someone else would pop up and say "This is what I do" but sadly nobody has yet done that.

Thanks for your help Mario

[Mario]

Many users visit the community maybe once a week. Give it some time.
There are as many approaches to versioning as there are features in IMatch.

[thrinn]

I do not use panorama stitching often enough to justify having special rules for that. But if I had I would most likely make the filenames slightly different from my normal ones, e.g. using a special prefix oder suffix. I rename my photos anyway, so a Renamer step is always part of my workflow. Making the file names different from normal pictures would allow for more specific relation rules, grabbing e.g. only panorama related files.

For panorama stitching I would expect to have to select the necessary single pictures always manually. So, I would select the files for the panorama, then call a special "Panorama" Renamer preset, setting e.g. a prefix or suffix. Only after the renaming, I would start with Affinity to do the actual stitching.

This would be my approach - in theory, at least. Surely, some issues may pop up if I tried this in reality. But basically, I would try to use slightly different file names to support different version rules.