A possibility to set versions as top files in a version stack ...

sinus · January 17, 2014, 10:43:16 PM

... or a slightly improved proxy-system.

The reason is simple: In a collapsed version stack users want often display the best version on top, and this is often not the master (raw), but a version (jpg, tif...).

This is not possible now, except with Proxies. But with proxy the problem is the expanded version stack, then we see mostly two identical thumbs.

More details are in the thread
https://www.photools.com/community/index.php?topic=1607.0

In short, this is my feature request, to enhance with a small changing (I think) the version stack system:

Versions with Proxies:
- in the collapsed view show a changed version-icon and display the proxy
- in the expanded view do NOT display the proxy
(I upload two pictures to show this, in the first picture I changed slightly, but visible, the icon for the master)

OR

- Let the user choose, that a version is on top of a collapsed version stack.

Would be nice to have this, because otherwise the super!!! relation - system with version stacks is not really useful, in my opinion.

Thanks for listening.

[attachment deleted by admin]

Ferdinand · January 18, 2014, 09:41:53 AM

I support this.

Ger · February 01, 2014, 08:26:38 PM

I do support this as well.

bonsai · February 02, 2014, 09:33:42 AM

Me too...

BenAW · February 02, 2014, 12:10:06 PM

Hi Markus

I think this open feature request also covers what you're looking for?

https://secure.photoolsweb.com/mantis/view.php?id=463

Mario · February 02, 2014, 03:27:54 PM

Linking to Mantis is not useful for 95% of all testers. They don't have access to the old Mantis system.
Better to posting feature requests here so all testers can see them.

Mario · February 02, 2014, 03:33:31 PM

Question:

How would one specify which version to use as the stack top in a version stack?
Manually?
Via the relation rule?
If via the relation rule, what if there are multiple files matching a rule, e.g. your version rule picks up two JPEG files, or a JPEG and a TIF file? Which one to use as the stack top?
What do display if the version selected as the stack top also uses a proxy?
How to deal with version chains, where the version picked up for open master is a master for another rule, and gets a different top from that rule?

Maybe removing version stacks completely solves this problem. Maybe add an option to "stack files in version set" to form a normal stack, with all the options to change the top via the user interface available?

The version stack was an afterthought, to allow users to easily hide versions from a file window. It's implemented in a way that the master is always and fixed the stack top. Changing this to allow for variable stack tops for version stacks will require substantial changes in several areas, database schema changes etc. Can easily take 40 or more hours or more to design , implement, test and document.

sinus · February 03, 2014, 11:11:52 AM

Quote from: Mario on February 02, 2014, 03:33:31 PM
Question:
Changing this to allow for variable stack tops for version stacks will require substantial changes in several areas, database schema changes etc. Can easily take 40 or more hours or more to design , implement, test and document.

Hi Mario,
I can see, this is not easy (I thought, automatic rule, if there are several pics, then take the first one in the sorting).

But what about my first proposal, would this be also so complicated? I think, if IM5 would have a behaviour like I proposed, MY problem (and I think, I am not the only one) would be solved.

Because we have an option to choose, what is the proxy, could this not be an easy solution? This here:

Versions with Proxies:
- in the collapsed view show a changed version-icon and display the proxy
- in the expanded view do NOT display the proxy

(I upload in the first post two pictures to show this, in the first picture I changed slightly, but visible, the icon for the master)

This would mean: I can choose a proxy for my version stack. If collapsed, I can see the image a the top file, what I wished to see, the proxy.

If I expand the version stack, mostly it makes not a lot of sense, to see then the proxy and the version side-by-side, because they are often the same.
Hence, in the expanded view, simply do NOT use the proxy (like I had NOT enabled the proxy in the preferences), and IMatch would nicely show the master and the version side by side.

I have not a clue, if this is easy doable, but since Mario is Mario, I hope, Mario will find a clever solution, because Mario sees the problem, what I described

sinus · February 07, 2014, 10:35:08 PM

I tried this again with build .138

It is realy very domage, that this does not work.

I imported 800 images.
IMatch did detect them perfectly!!! And in fact very quickly! GREAT.

Usually I (and a lot of users will have too) have some masters without any versions, simply because these pics are not very good.

So I have some masters with one version.
Without enable Proxy the expanded version looks fine,
but in the collapsed version the master in on top and this looks not good, because it makes not a lot of sense to show the raw on top instead the edited, good version.

With Proxy enabled it is the contrary: the collapsed version looks fine, because the edited (proxy) image is on top.
But in the expanded version both images looks the same, because the raw is now the proxy. And this makes also not any sense.

That is why I posted the feature request.

Mario · February 08, 2014, 08:04:55 AM

The idea behind the visual proxy is to handle cases where you edit a RAW in an application like LR (or another RAW editor). From then on, the RAW will look totally different in LR and in IMatch because IMatch cannot apply the render instructions which are proprietary to LR and not accessible from the outside.

You can now export a "final" version of the RAW from LR and then set this version as the visual proxy for the RAW. The RAW now looks in IMatch as it looks in LR. This is also the case when you collapse a version stack, because the master is at the top. The stack looks like the image in LR. When you expand a version stack this does not because the visual proxy is still applied. The visual proxy is independent from version stacks. Or regular stacks.

You can see the original RAW at any time in the version panel. And in the Viewer, when you set the corresponding option.

I have not yet got any answers on how I could implement the requested change (specifying a version to be used as the top of the stack when a version stack is collapsed). I have not thought about this yet much. I'm currently concentrating on bug fixing and performance Stabilizing. Marketing materials for the release etc.

Enabling/Disabling the visual proxy depending on whether or not a version stack collapsed is another feature request.

Ferdinand · February 08, 2014, 08:51:56 AM

Quote from: Mario on February 08, 2014, 08:04:55 AM
I have not yet got any answers on how I could implement the requested change (specifying a version to be used as the top of the stack when a version stack is collapsed). I have not thought about this yet much. I'm currently concentrating on bug fixing and performance Stabilizing. Marketing materials for the release etc.

Well, I was put off by your comment that "Can easily take 40 or more hours or more to design , implement, test and document". V5 needs to be out asap.

That said, I would suggest another option like the visual proxy option. The version stack proxy option would be configured in file relations the same way as the existing visual proxy, but be used for version stacks. Its behaviour in the presence or multiple matches would be the same as the visual proxy - use the first one found. I.e. it's up to us to ensure only one match. As for the other questions, I'd go for the simple option - always use this proxy even if the version stack proxy has a proxy itself. I'm not sure about version chains.

Mario · February 08, 2014, 12:06:41 PM

Very good. That's along the line I'm thinking as well (both statements)

That's why I setup the 'verb' system - I expected that other special uses or verbs would bubble up once users start using IMatch for productive work. We'll get plenty more once we're 'official'. I'll look into this again after the initial release is out.

sinus · February 08, 2014, 02:15:32 PM

Quote from: Mario on February 08, 2014, 12:06:41 PM
Very good. That's along the line I'm thinking as well (both statements)

That's why I setup the 'verb' system - I expected that other special uses or verbs would bubble up once users start using IMatch for productive work. We'll get plenty more once we're 'official'. I'll look into this again after the initial release is out.

Thanks Mario, in looking later into this, and Ferdinand, thank you also very much for your ideas.

cytochrome · February 10, 2014, 09:48:06 PM

Quote from: Mario on February 08, 2014, 08:04:55 AM
....
I have not yet got any answers on how I could implement the requested change (specifying a version to be used as the top of the stack when a version stack is collapsed). I have not thought about this yet much. I'm currently concentrating on bug fixing and performance Stabilizing. Marketing materials for the release etc.
...

I do not (yet) use versions stacks nor labels or stars. But this would be a reason for me to use them.

Use a color pin to designate my preferred version and have IM taking care of putting always on top.

Francis

Mario · February 11, 2014, 07:51:26 AM

With normal stacks you are in full control over which image you put on top.

The additional automatic version stacks always put the master at the top. Which is fine for many workflows, but not for all. Not even with proxy images, apparently.

Ferdinand · February 13, 2014, 11:17:42 AM

Quote from: Mario on February 11, 2014, 07:51:26 AM
The additional automatic version stacks always put the master at the top. Which is fine for many workflows, but not for all. Not even with proxy images, apparently.

Apparently. Although you've already agreed that more verbs are possible, let me explain why this one would be useful in my workflow.

I shoot in RAW (colour embedded thumb) but render a lot of my work in B&W. If I was to use a visual proxy for the RAW file, then I would see a B&W image for the RAW file. I'd find this confusing. At a quick glance I'd think I was looking at a developed image and not the RAW. So I decided not to use a visual proxy.

However when I look at a collapsed version stack, I tend to think of the version set in terms of the final developed image, which is B&W. But at present I see a colour image on top. I'd rather see a B&W.

So this is why I would like a version stack proxy, but won't use a visual proxy.

p.s. This additional comment is not meant to suggest that this is a high priority - it isn't.

sinus · February 13, 2014, 12:00:31 PM

So, what Ferdinand wrote, is exactly, what I think too.

If I have 20 collapsed versions, I would like to see on top the version, not the RAW.
Usually, I think, in a collapsed version-set, you will show and look at some good looking versions, not the "clumpsy, raw" Master.

But if expanded, then I would like to see the Master in its original view (not the good looking proxy), AND I want to see one or more (good looking) version.

I am really sure, that a lot of users would and will with this.

But also, like Ferdinand, I must say: It is not a high-priority - wish

Michael · June 21, 2014, 05:46:24 AM

could you allow a priority list of ext so that the version with a ext that matches highest on the priority is what is shown as a representative of the stack. This priority list could have a default but is user managed. for instance. I have a fairly simple workflow. RAW then PSD and then JPG
Always a RAW, often a PSD and sometimes a JPG. I setup a relationship that uses the PSD as the master and includes the JPG and NEF as related files. now I there is only a RAW, I see that on top, if there is a PSD I see that on top. This only works for a very simple flow. a Priority list would make it more versatile. I guess you could also just say, most recently edited or created to determine what is "on top".

anyway , great feature. thanks

Jingo · June 21, 2014, 04:36:27 PM

I found through testing (and THEN reading the help

) that the proxy versions are simply setup by the first filename in the version stack... if one has a lot of versions, it becomes very important to note your naming conventions to ensure the correct image is the proxy view version. I was hoping there might be a way down the road to choose the exact proxy from the version panel via a right click from within the stack? Perhaps have it assigned a different color tag as well to quickly note which is the proxy. Default could still be the naming convention but this would act as an override if it is in place.

Erik · June 21, 2014, 11:11:07 PM

I support the concept as proposed by Ferdinand.

To go along with my feature request related to ratings and labels. In IM3.6 I used to rate and label versions for files (versions being created using the scripts available). Stacking was achieved in my workflow by labeling the best image with a specific color and using a filter to "stack" images with only the best version showing. It could be nice to be able to use a filter to float a best version to the top of the stack if one used labels or ratings to identify a best of or representative version.

sinus · July 24, 2014, 11:23:09 AM

Because I am just working with versions stack, I stumbled again over my feature request, reread it and want to show MY view also with some attachements, maybe then will be clearer, what I asked for.
I think, usually a user has a master (raw) and no versions, or one or more versions.

IF she/he has versions, and the thumbs are expanded, one wants to see the difference between masters and versions quickly, also only on the thumbs (without the version panel).

If the version-stack is collapsed, I think, a user want NOT see on top the raw-file, but the fine, edited version.
At least, I think, that most of users wants such a behaviour.

To show this clearer, some attachements:

1) attachement 1
Proxy off, Version stack expanded, we see CLEAR and fast the masters and versions, for me FINE

2) attachement 2
Proxy off, Version stack collapsed. Now we want spare some room and do collapse this version-stack. Now the masters are on top, the fine and edited versions are hidden behind each master. I think, this is not what a user wants.

3) attachement 3
Proxy on, Version stack collapsed. Ah, we have proxies, so I put the proxies on and, voilà, this is a collapsed view, what a user want to see. I can see my edited version on top and I now, behind are my masters, what are looking not that good.
The only (minor) thing is, thought the jpg (proxy) is on top, there is written (if we have configured this) on the thumb layout "nef" instead of "jpg" or whatever version-format. But this is really a minor thing.

4) attachement 4
Proxy on, Version stack expanded. So fine, let's expand this and ... we see instead clear distinguished master and version, allmost the same (versions) and can only see, what is master with the icon. Also the format is written "wrong", the master is written with "nef", but shows the jpg-version.

So, FOR ME, the ideal design would be, for the expanded version-stack a look like the first attachement, the format is written correct (minor) and we can cleary distinguish between master and version. Fine.

And for the collapsed view, I would prefere a look like attachement 3, all edited version are on top.

But this is currently not possible, because attachement 1 is the proxy off, with attachement 3 proxies are on.
I hope, this makes my feature request a bit clearer.

[attachment deleted by admin]

thrinn · August 02, 2014, 06:07:35 PM

+1

Pawel · March 12, 2017, 07:38:42 PM

Quote from: Ferdinand on February 13, 2014, 11:17:42 AM
Quote from: Mario on February 11, 2014, 07:51:26 AM
The additional automatic version stacks always put the master at the top. Which is fine for many workflows, but not for all. Not even with proxy images, apparently.

Apparently. Although you've already agreed that more verbs are possible, let me explain why this one would be useful in my workflow.

I shoot in RAW (colour embedded thumb) but render a lot of my work in B&W. If I was to use a visual proxy for the RAW file, then I would see a B&W image for the RAW file. I'd find this confusing. At a quick glance I'd think I was looking at a developed image and not the RAW. So I decided not to use a visual proxy.

However when I look at a collapsed version stack, I tend to think of the version set in terms of the final developed image, which is B&W. But at present I see a colour image on top. I'd rather see a B&W.

So this is why I would like a version stack proxy, but won't use a visual proxy.

My thoughts exactly - when I look at collapsed version stacks I'd like to see finished images, when I look at all the versions (version stack expanded) I'd like to see "raw" images.

I think the easiest solution would be to leave everythink as it is now, only add an option for the File Window to show or not visual proxies (as it works in Viewer now) - regardless whether the version stacks are expanded or not. Then one would work in File Windows as it is in Viewer now. In fact, seeing "T,X" shortcut in Viewer I was looking for similar solution in File Window and was surprised it wasn't there, it seemed so natural.