Versioning visual proxies – use last rather than first file as visual proxy

[vbt]

When a number of versions of the same file exist IMatch sorts the versions by file name and uses the first file as visual proxy. I would like a system option to use the last file rather than the first. (In other words I always want to use the last file rather than the first but I recognise this needs to be a system option as others will prefer the current rule.)

This may seem an unnecessary request since I have full control over the filenames and so can always choose to change the filename of the file I want to use as the visual proxy so that it is used. And indeed this is the work-round I currently use. However it has downsides. Firstly I usually need to rename two files and secondly when my version stacks are expanded the files are not in the most obvious order for me.

To understand let me explain my naming convention and workflow. All files from my camera are named YYYYMMDD-hhmmss[-n].rw2 or  YYYYMMDD-hhmmss[-n].jpg.

Then as I edit I add a suffix "+V1" "+V2" and so on for each new version so a typical version set of photos might be:

20200106-170000.rw2
20200106-170000.jpg
20200106-170000+V1.jpg
20200106-170000+V2.jpg

Now in practice I am most likely to want the final photo to be the visual proxy for the set. If my feature request was implemented then I would not need to rename any files. However I currently need to rename both the camera produced jpg (which I find quite annoying since ideally I would always want my camera produced jpg to have an identical name to the raw file). I then also need to rename the last file. So the list of files (with changes in bold) becomes:

20200106-170000.rw2
20200106-170000+Z.jpg (to stop camera produced jpg being the first version file)
20200106-170000+V1.jpg
20200106-170000+D2.jpg (to ensure the last file becomes the first version file and therefore the visual proxy)

My files will then have the correct visual proxy. But when the version stack is expanded the order will no longer be in order of edit progression, which again is not ideal.

Having said that I do like that using the filename to create the versions rather than relying on some data that is stored in IMatch's database. I like that the version stacks can be recreated automatically just from the files themselves.

[Mario]

Have you considered using two version rules. A second rule which only matches the versions you want and then make this the visual proxy?
This would solve your problem I guess, without the need to add features like "Always use the nth version when sorted".

[vbt]

I have given this some thought and I can't see how a second rule would help.

For the avoidance of doubt I am asking for the last version (in filename order) to be used. (I personally would not refer to that as the nth version as that seems a bit ambiguous to me - it might be read as n being the same number for every version set, which is obviously not what I am requesting).

[Mario]

For your use case and your file naming schema etc. it may be always the last file name, assuming an alphabetical sort. For other users it is the first version. When I would add features to tell which of the found versions in a single rule should be considered, I'm sure there will be one user who wants the 2nd or one before the last.
There would be never and end to this...

Hence I always recommend to use a file naming schema which makes it deterministic which proxy is used (if you really end up with a versioning schema which makes multiple proxies possible). Or use use a separate rule only for the visual proxy. If all that is not possible, this may be a case where IMatch has to say "cannot do, sorry".

Let's see how many other users read your request and if they have the same problems.
If this is something that affects multiple users, I will think about it.

[sinus]

I personally like it as it is.

Because I have full control over it with the naming-system.
And btw, I  want not always the last image is as the proxy, because I do often use e.g. web-images, and I do not want such images as proxy.
If I want to be the last file as the proxy, well, then I can always renaming this file.

in your system:
20200106-170000.rw2
20200106-170000.jpg
20200106-170000+V1.jpg
20200106-170000+V2.jpg

Could you not change your naming - system to another?
I can imagine several.

Like:
20200106-170000.rw2 (original rw2)
20200106-170000+p1.jpg (is normally the proxy)

Now you add versions:
20200106-170000+v1.jpg
20200106-170000+v2.jpg

Hence the sorting is like above, the wished original jpg is the proxy.
But now you want that the last (+v2) is the proxy.

Simply change this name from
20200106-170000+v2.jpg to
20200106-170000+p0.jpg

and your last file will be the proxy.
And you know:
Everytime, if you want have another as p1 for the proxy, create for such a file p0.
You can let p1 (the jpg-original) p1, this will be ordered after the new proxy (p0).

But this is only one possibility, but thinking about naming-system can help a lot.

[vbt]

I fully understand why many people will prefer the existing rule for visual proxies, which is why I suggested the alternative be set as a system option. So those, such as yourself, who prefer the existing rule don't need to change anything. (Whereas others such as myself could change the option from its default of first file to last file.)

The problem for me with the alternative naming convention you are suggesting is that I cannot keep the camera jpg and raw file with the same name even when there are no other versions. My existing naming convention keeps them the same unless I have other versions, when unfortunately I am forced to break this convention if I want another file to be the visual proxy. Another problem is that when the version stack is expanded the order the files are shown will not normally be the order I would want. (Also my feature request would still give me full control if I wished, as I would on occasion, to use a file other than the last one as the visual proxy. I would then have to rename one of my versions, rather than two currently, and my camera produced jpg could keep the same filename as its corresponding raw file.)

I have given my naming system a lot of thought. It meets a lot of aims I haven't explained here which are not relevant to the feature request.

But my key point in this post is to explain that my feature request would not mean any existing users would need to change their behaviour. (And I would have no objection if instead of just a simple option to select last named version  other options such as nth were also available.)

[Jingo]

But my key point in this post is to explain that my feature request would not mean any existing users would need to change their behaviour.

Unfortunately - more options can also lead to issues.  Having lots and lots of user defined options creates complexity in the settings (and it is already quite complex!), additional documentation in the help system and the possibility of introducing bugs and interactions to the existing codebase (now and in the future). 

I point to XYPlorer as an example of this... love the program and the amazing things that can be done with it.. however, the sheer amount of user defined options that have been added over the years for individual requests is staggering... they had to add a "search" feature to the settings box in order to find what you are looking for! 

I'm all for flexibility... but agree with Mario's view to code things for the majority and see how the feature request is received by users who frequent the boards.

[sinus]

The problem for me with the alternative naming convention you are suggesting is that I cannot keep the camera jpg and raw file with the same name even when there are no other versions.

I do not know your naming - system, hence I do not know, if this is possible like in my test:
simpy create an own sorting, here:

first filename without extension
second extension, but in reverse order

Then you had the raw first, followed by the jpg with the same filename.
See attachement, where the green first would be the raw, followed by the original jpg from the cam, than the versions.

[vbt]

Thanks for thinking about this.

I think what you are suggesting is pretty much what I do already. And the files you have shown are in the order I would wish (and achieve) when expanded provided I am happy with the camera produced jpg being the visual proxy which is seldom the case if I have created other version(s). The problem is that typically the photo I want as the visual proxy will be the last one when expanded i.e. 20200106-170000+V2.jpg. (So I then need to rename two files and lose the expanded order I want whereas my feature request would mean I would not need to do either of those things when, as would often be the case, I want the last edited version to be the visual proxy.)

However in case I am misunderstanding I will explain try and explain my naming convention and workflow in slightly more detail using examples.

When I take raw+jpg in camera then I rename the files based on date and time (to the millisecond) with an optional number to ensure uniqueness if necessary (e.g. if I have taken a few photos in burst mode).

So six photos (or really three raw+jpg pairs) taken today might be:

20200107-144915.jpg,
20200107-144915.rw2,
20200107-144915-1.jpg,
20200107-144915-1.rw2,
20200107-152505.jpg,
20200107-152505.rw2,

(Note that two pairs of raw+jpg were taken at the same time to the millisecond. This is not common but nor is it very rare.)

I have a versioning rule set so that rw2 is the master and any jpg file with the same name or the same name immediately follow by "+" (explained later) will become a version. (This is a slight simplification but I don't think further detail is necessary or relevant here.)

Now supposing I wish to work more with the 20200107-144915.rw2 photo. If I create a new jpg version of it then I will add "+V1" to the name and it is automatically recognised as another version of that master.

I now have the following seven files:

20200107-144915.jpg,
20200107-144915.rw2,
20200107-144915+V1.jpg,
20200107-144915-1.jpg,
20200107-144915-1.rw2,
20200107-151005.jpg,
20200107-151005.rw2,

And if I later make a further subsequent version from the same master (or any of its versions) I would add +V2 to the filename. So I would then have the following 8 files:

20200107-144915.jpg,
20200107-144915.rw2,
20200107-144915+V1.jpg,
20200107-144915+V2.jpg,
20200107-144915-1.jpg,
20200107-144915-1.rw2,
20200107-151005.jpg,
20200107-151005.rw2,

Now they have been named to appear in the correct order when expanded. I want to see my edited versions in the order they were created. But now suppose I wish the latest version i.e. 20200107-144915+V2.jpg - to be the visual proxy for its version set. Currently I need to rename both it and 20200107-144915.jpg.  I rename +V2 to be +D2 since D comes before V (and I keep the 2 so I know its actual creation order) and I add a +Z to the file 20200107-144915.jpg to ensure it is not still first. This works in so far as the visual proxy is what I want.

The downsides are:

1) I have had to rename the camera produced .jpg file.
2) When expanded the best order I can get (which is I think the order you are sugggeting) is

20200107-144915.rw2,
20200107-144915+D2.jpg,
20200107-144915+V1.jpg,
20200107-144915+Z.jpg,
20200107-144915-1.rw2,
20200107-144915-1.jpg,
20200107-151005.rw2,
20200107-151005.jpg,

which is not quite what I want. I want the raw file, followed by its versions starting with the camera jpg and then in the order I created i.e. v1 followed by v2 etc.

3) I also need to rename files every time I create a new version if I want that new version to be the visual proxy, which is often (but not always) the case. 

If you are suggesting that by using some sort of custom sort order (along with some adjustment to by naming convention) I can achieve my aims then I am interested. But I can't see a way to do it since as far as I can see there is no way to make the desired version have a name that will appear alphabetically before the camera produced jpg without either renaming the camera produced jpg or creating other problems.

[Carlo Didier]

The problem for me with the alternative naming convention you are suggesting is that I cannot keep the camera jpg and raw file with the same name even when there are no other versions.

In my case, I use a JPG with the exact same name as the raw file as the proxy. This can be the JPG from the camera or generated by ACR/Photoshop/C1/whatever.
Any other versions get something appended to the name. For me, the visual proxy is a preview of the first "version" of the image. I don't want any other version as the proxy because those are derived from the first original "version" and I would then loose the ability to compare to that original version.

[vbt]

Your response has made me realise I have been using the wrong IMatch terminology. Rather than visual proxy I should have used "version stack visual". I hope I have not caused too much confusion.

What I want for the "version stack visual" is the picture I am happiest with from that version set, which is usually (but not always) the last version I have created. (I don't actually use "as visual" at all.) And when I expand a version stack I want to see all the versions starting at the left with raw and proceeding in the order the versions were created.

In any event my feature request would not lead to any change for existing users (unless they wished to make use of the new feature).

[JohnZeman]

Your response has made me realise I have been using the wrong IMatch terminology. Rather than visual proxy I should have used "version stack visual". I hope I have not caused too much confusion.

+1 for something along these lines.

Right now the only way to automatically set the stacking order the way we want, other than the default alphabetical that is, is to increase the rating of the image we want to be the top of the stack.  That's what I had to do a while back when my masters were TIFs and my versions were JPGs.  After stacking I returned the TIF Masters ratings back to what they were before.  Kind of a clunky way to do it but it worked.

It would be nice if there were more options to set the top image of a stack.

[sinus]

Your response has made me realise I have been using the wrong IMatch terminology. Rather than visual proxy I should have used "version stack visual". I hope I have not caused too much confusion.

+1 for something along these lines.

Right now the only way to automatically set the stacking order the way we want, other than the default alphabetical that is, is to increase the rating of the image we want to be the top of the stack.  That's what I had to do a while back when my masters were TIFs and my versions were JPGs.  After stacking I returned the TIF Masters ratings back to what they were before.  Kind of a clunky way to do it but it worked.

It would be nice if there were more options to set the top image of a stack.

Hmmm,
John, are you sure?
I think, you are talking from stacking, where you can stack every file, what you want have in a stack.
(from the help: Stacking images is a great way to reduce the number of images you have to look at in file windows. Just stack related images to clean up the file window.)

But here, I thought, we are talking from version stacks
(help: The Versions concept allows you to track different versions or renditions of the same file, e.g. DNG or JPEG versions of  RAW or multiple generations of a PSD or Office file.)

[JohnZeman]

Maybe you're right Markus, I might have misunderstood what vbt was asking for.

[Mario]

@John

I'm not sure that I can follow.
Do you use regular stacks? In that case you control which file is on top. And you can switch the stack top quickly.
Or do you create regular stacks via auto stacking (because you refer to the rating and that's an option there).
Or do you use version proxy via file relation rules? In that case the "first matching version used" rule applies (which is the OP's point).

[JohnZeman]

I was talking about regular stacking Mario, specifically autostacking.  Where our only option to set the image on top of the stack during autostacking (other than default alphabetical) is by rating.

Apparently I misunderstood what vbt is asking for.
Apologies, I didn't mean to hijack this thread.

[Mario]

I see. Different thing.
The options for auto stacking seem to work for most users. Feel free to open a FR if you suggest some additional features for this tool.

[sinus]

In Attachment 1 there are 3 pictures, collapsed, all Masters and all have the original as proxy - jpg from the camera.
(I have only written "Original-jpg" in the jpg, so you can see that).
So these are 3 Masters (recognizable by the icon below and the extension on the top right), which are displayed with the (first) jpg.
Additionally you can see the word "MASTER" below.

Attachment 2 shows the same, but expanded (toggle t).
The original jpgs follow immediately after the Masters.
Versions 1 and 2 behind them.

But now I want to have the 2nd version as a proxy, the red grid should appear as a picture at the master.
That would be the number 20200107-144915+V2.jpg
So you have to make sure that this image is sorted right after the master.
Because then it becomes the proxy.

So it would be normal to rename the original jpg and the desired new proxy. With an appropriate workflow this would work fine.
But now user "vbt" doesn't want to rename the original jpg (which I don't quite understand, but that's how it is).

So I have to rename the 2nd version (which I want to have as proxy) "unconventional", e.g.
20200107-144915.+V2.jpg (point after 5)
20200107-144915 +V2.jpg (space after 5)

Attachment 3
This makes the V2 version a proxy WITHOUT having to rename the original jpg.
But in the order the 2nd version is no longer at the end.

The proxies vote for it (Attachment 4).

And the whole thing is based on an own sort order. (File-Extension reverse order), see Attachment 5.

Maybe we can find with further investigation a solution for this.
With renaming some files (also original-jpgs) we would be more flexible to achieve this (maybe).

But of course with an implemantation, like "vbt" asks with his feature request, this would be easy possible.

But how much work this would mean for Mario, I have not clue.
And how many users would need this, I do not know.

I personally must not have this feature, but of course, if it would exist, maybe I would use it from time to time.

[Mario]

But how much work this would mean for Mario, I have not clue.
And how many users would need this, I do not know.

That's always the tricky question...

I would guess about one working day to implement this:

- Changing the dialog and updating all code in IMatch which tests for versions.
- Testing.
- Finding and re-creating all related screen shots in the help
- Updating the help to explain the new addition.

This all sounds not much but it adds up. And when only one user will ever have a use for this, its not worth it.
I could do a new feature helpful for 500 users in the same time.

[Mario]

I was talking about regular stacking Mario, specifically autostacking.  Where our only option to set the image on top of the stack during autostacking (other than default alphabetical) is by rating.

Just in case you are not aware (I doubt it): You can quickly make any file in a stack the top by selecting it and pressing Ctrl+CursorUp or Shift+T. This is true even for stacks created by Auto-Stacking. I guess this would be faster than to fiddle with the rating to make a specific file the top..?

[JohnZeman]

Thanks Mario.  Yes I'm aware I can set any image in a stack as the top image by using those keystrokes.  But unless I'm missing something I can only do that one image at a time right?

For example if I want to autostack 1000 TIFs (masters) and 1000 JPGs (versions) and I want the TIFs at the top of the stacks at the end of the autostacking the only way I've found to do it automatically is by temporarily changing the TIFs rating so they're higher than the JPGs.

Fortunately this is not an issue for me now since I have already created all of my TIF/JPG stacks (with the TIFs at the top) and I rarely have TIFs as my masters/top of the stack.

Just thought it would be nice if there was a way to set which image format will be the top of a stack during autostacking.

Thanks again.

[Mario]

I didn't want to make the AutoStack feature to complicated or add to many options.
The ability to optionally pick the top by rating is what aligns with most people's workflow (other DAMs with 'auto stacking' offer the same option, for example).
Adding extra options to pick the stop by file format (what if no file with that format is in the stack?), by date (oldest? newest?), by file name (first? last?) etc. are thinkable and doable - but how many people would need this?

If you need this often, add a separate AutoStack feature request (because this is unrelated to version proxies).
Then we'll see if there are others who also find this useful.

[JohnZeman]

Got it, thanks Mario.