Renamer/Move Files Help

[lnh]

I've been consider making a change going forward with the directory structure of how I store image files...

I'll typically, but not always shoot RAW, and make the RAW file the master and any jpgs and derivative files versions. Obviously, if only a JPG was shot, that is the master, but derivative jpgs or other file formats are versions. My file relations/buddies seem to work well for me and do just what I want.

My workflow is to:
1) Attach lat/long/elevation via Geosetter (with become IMatch 2017 with new map panel) if a GPX track exists
2) Import into IMatch and set file relations/buddies.
3) Use ECP on master to modify date/times if camera was not set to local time zone and/or modify date/times from GPX track time compensation between camera clock and GPS time.
4) Rename master with the pattern: yyyy-mm-dd_(hr_min_sec).extension. Versions/buddies follow automatically.
5) Move master from my "ingest" folder to: drive:\IMatch\{File.DateTime|format:YYYY}\{File.DateTime|format:MM}\{File.DateTime|format:DD}
6) All other work with IMatch and image manipulation

What I'd like to consider is only keeping masters in the folder which results from the above steps and have all versions sit one level deeper in a folder named "Versions".

In the renamer I've played around with the variable File.Relations.IsVersion but can't figure out how to use this in an automated way so versions sit in the "\Versions\" folder and masters sit where they are today.

Is what I'm attempting possible?

[Mario]

If you want to change the name of the output folder depending on whether or not the file is a version you can just use is to check the result of isVersion and then return different folder names:

{File.Relations.IsVersion|is:1,NameOfVersionFolder,NameOfOtherFolder}

try this out in the Var Toy to get a feel for what it does.
Use this i.e. as part of the output folder name...

[lnh]

Thank you. Made some more progress, but got stuck again and trying different options, variables, etc still has me scratching my head.

To simplify a bit until I get this right, I'm not trying to move and create the whole folder hierarchy yet, and just want to see if I can get it to place "versions" in the \version subfolder of where the files are currently sitting.

The "Example" source file / destination file in the Copy/Move detail configuration window looks good, but when I back out to the Renamer window it clearly isn't doing what I hoped which is confirmed in the Preview. I've tried various file variables instead of using "Original File Name" which appears to not include the path to that name. Must be doing fundamentally wrong.

[Mario]

I'm not sure that it is possible to combine folder tokens like {p0}with variables. Nesting variables is possible, but not nesting folder tokens.  This is just not implemented/impossible to parse reliably. You need to use a 'real' folder or another variable, not {p0} or similar. I have not tried this, but this is the most likely explanation for your output folder resolving to an empty string.

[sinus]

I've been consider making a change going forward with the directory structure of how I store image files...

I'll typically, but not always shoot RAW, and make the RAW file the master and any jpgs and derivative files versions. Obviously, if only a JPG was shot, that is the master, but derivative jpgs or other file formats are versions. My file relations/buddies seem to work well for me and do just what I want.

I am just curious: Why want you do this? I have the same structure like you (I think), but have masters and versions in the same folder. Has advantages, but of course also disadvantages. But hold versions in another folder has also pros and cons.

Hence I am only curious, why you want change your (good working) directory structure?

[lnh]

I am just curious: Why want you do this? I have the same structure like you (I think), but have masters and versions in the same folder. Has advantages, but of course also disadvantages. But hold versions in another folder has also pros and cons.

Hence I am only curious, why you want change your (good working) directory structure?

To be honest, I'm beginning to wonder why I'm considering doing this as well. As you say, it has pros and cons. Thought it would nice to just see masters without having to filter and/or toggling the version stack. Also, something seemed "right" about keeping files of a similar status together. If you're jumping off into editing from IMatch, you would be more certain to start from a master. At this point the cons seem to be outweighing the pros.

On a philosophical note... Many years ago a senior CS engineer I knew thought it best to dispense with folder structure for organization and when you need to find something just search using data & metadata. He was speaking more generally and not just about photos. IMatch gives you all the tools to take this approach so it must be some OCD tendencies which makes me want  to organize via a file structure as well. Maybe at a base level a date based file structure is a crude one dimensional backup to IMatch and makes systematic backups using other tools easier and knowingly complete. When you think about how Google Photos works and where it's headed, it's all about metadata as extended by machine learning (and kept private from the user and forms what Google learns about you).

[sinus]

I am just curious: Why want you do this? I have the same structure like you (I think), but have masters and versions in the same folder. Has advantages, but of course also disadvantages. But hold versions in another folder has also pros and cons.

Hence I am only curious, why you want change your (good working) directory structure?

To be honest, I'm beginning to wonder why I'm considering doing this as well. As you say, it has pros and cons. Thought it would nice to just see masters without having to filter and/or toggling the version stack.

Here I can feel with you.
Sometimes we want quickly see only the masters or the versions and so on.
We can of course filter, but do not ask me why, I tried several times and it works! ... but I have never been so fine with the filter-system. As I said, do not ask, why, I do not know. 

But we have different possibilities to do this also without filters.
I created for me some scripts (puh, will be also not more useful, if IMatch 2107 is out), where I can select a (mostly stacked) image, and let the script run (favourites).
It expands all images and puts them into a special category, what it divided into Master and versions. So I can easy switch between both. See my attchement.

I have all masters and versions into one folder, even some outputs (contact with Print & Design) or even bills. I stacked all this from one event into one stack.
This also has again some disantvantages, but also some goods. And to see for example all bills together, easy, we have collections or search functionalities, data driven categories and yes, filters.

I think, we have with IMatch different possibilities and there is not "the best one".

I go with the words "never change a winning team"! 

But, because I am quite consistent with filenaming and collections and so on, if I want change one day, I think, I can do it quite easy with IMatch.
And the new JavaScript gives also some possibilities.

BTW: funny, I MUST have now a new program for accounting, I found one (banana) and guess what? It offers some apps and we can write new ones ... all in JavaScript. Phew, I ought to lern it quicker and better. Since I have some bill-information in the attributes of an image (one info-master per event), this could give some interesting possibilities.

attached:
1 a folder-structure
2 files in one month of this folder structure
3 a category structure
4 files in the category structure

[lnh]

I've been testing another change to my setup to make it more flexible.

Normally files get added and renamed before derivative (version) files are created, with the exception of out of camera JPGs which as described earlier are a version of RAW or a master if a RAW wasn't captured. That is the ideal, but the reality is that sometimes files get worked on before hitting IMatch and I'd like to streamline the process of getting them setup following my relation/buddy rules and file naming convention.

I name derivative files in a specific way. For example if the Master file out of the camera was P3230027.ORF, a version out of Affinity Photo might be named P3230027_1000px-Q80_AP.jpg (1000 pixel long dimension at quality 80 produced with Affinity Photo) and so on. So the issue when renaming inside IMatch (using the convention mentioned in the initial post) is to have those two files become 2017-03-23_(14-58-36).ORF and 2017-03-23_(14-58-36)_1000px-Q80_AP.jpg.

I know this can all happen auto magically if I make derivative files buddies as well as versions and just changing the name of the master. However, making derivative image files buddies also seems to have downsides.

I've tried to make this thing happen with the versions without success. The image below shows how I've approached it. There is probably a much simpler way I'm not understanding. The Regex code in the renaming process seems to check out when I test it on regex101.com. Any help would be appreciated.