Automatic cascading options

[Mke]

Further to Vlad's Mantis feature request #2633, reproduced below...

Ok, here is one more proposal to improve the version set functionality (by making it more flexible but also more transparent): I request global catalog settings for *automatically* cascading metedata across version sets, similar to the existing options for manual cascading:
- for image details (XMP)
- for ratings
- for color labels
- for GEO coordinates (as requested in 0002367)

For backwards compatibility, all these settings should probably be disabled by default. Once such a setting is enabled, any *subsequent* change to applicable metadata in *any* version must automatically propagate (cascade) to the whole version set. (However, enabling a setting does not need to trigger any immediate metadata cascading across the existing version sets in the catalog.)

The existing functionality of manual cascading must be still preserved (to achieve specific metadata cascading for specific version sets, if so desired).

N.B.:
Currently, labels are always automatically cascaded across version sets. I could see reasons for not desiring this, therefore an automatic cascading setting for labels (enabled by default) would be natural and welcome too. However, I don't find this particular cascading option a must, in case implementing it has far-reaching effects on the current PSU design and working assumptions.

...and as noted in my own Mantis comment, I suggest that it would be good if this automatic cascading could be based on the version place holder. So that, for example, ratings could be automatically cascaded to all versions except the 'web display' version, should the user choose to configure it that way. I thought it might help to mock-up my idea so you can see what I mean - this is how I could see it working in PSU's 'preferences'. I'm posting it here for any further comments, to avoid the Mantis ticket being sidetracked into this semi-detached discussion on implementation

Versioning & cascading.png (42.33 KiB) Viewed 8875 times

Thoughts?

[Mke]

BTW, I also posted some suggestions to Mantis (http://bugs.idimager.com/view.php?id=2873) a few days back on providing a means of copying 'face areas' to other images in a version set - one potential manual method, two using cascading. Should either of the cascading options be adopted, that could be added as another column in the above matrix too.

[fbungarz]

I think this is an excellent suggestion. Can't wait to get it implemented
Frank

[vlad]

Mke, thanks for improving my request and coming up with a nice mockup. A couple of comments and questions:

1) I would suggest catalog labels should be included in the cascading settings too (unless that makes the versioning logic too complex).

2) IIUC, the checkmarks for a placeholder would say that the respective kinds of info should be cascaded *to* that placeholder, right? Would the cascading source always be the main version or could it be any version? In the second case, I think there may be some potential for confusion; let's say that (V1, V2, V3) belong to the same set, with the cascading of ratings checkmarked in V3 only. If V1 gets 2 stars and V2 gets 4 stars and both images get synced, which star rating should V3 get? (Please don't say 3 stars... )

3) The same image may have multiple placeholders. In this case, would the cascading checkmarks be combined via OR (meaning: the info is cascaded if at least one assigned placeholder requests that) or via AND (meaning: the info is cascaded only if all placeholders request that)?

4) Currently, Catalog -> By Category displays only the main version because labels are automatically cascaded, while a view such as Catalog-> By Rating may display multiple versions, since ratings are *not* automatically cascaded. I think the display logic may get a bit tricky if only some placeholders get cascaded info. (Ideally, those should be "collapsed" by default in the corresponding view.) And, with the risk of (re)opening a can of worms, I would say the proper answer to that might be provided only if FR #2525 (selectable style of display w.r.t. version sets) is implemented too. (Fortunately, some practical proposals were made there too - you could see them summarized in my last ticket note.)

Cheers,
Vlad

[Mke]

1) I would suggest catalog labels should be included in the cascading settings too (unless that makes the versioning logic too complex).

Yes, you're right - labels should be included too. I'll update the mock-up at some point. I'm thinking that there may be other things missing too - like the contents of the Details panel...

2) IIUC, the checkmarks for a placeholder would say that the respective kinds of info should be cascaded *to* that placeholder, right? Would the cascading source always be the main version or could it be any version? In the second case, I think there may be some potential for confusion; let's say that (V1, V2, V3) belong to the same set, with the cascading of ratings checkmarked in V3 only. If V1 gets 2 stars and V2 gets 4 stars and both images get synced, which star rating should V3 get? (Please don't say 3 stars... )

I was thinking that everything should be cascaded from the main version, for simplicity.

3) The same image may have multiple placeholders. In this case, would the cascading checkmarks be combined via OR (meaning: the info is cascaded if at least one assigned placeholder requests that) or via AND (meaning: the info is cascaded only if all placeholders request that)?

A good point too. My feeling is that OR would probably be preferable - maybe easier to trace back why something has been cascaded, rather than puzzling about why it hasn't?
I guess it would be a good idea to display a warning/explanation (at the time of assigning multiple placeholders to an image) if the options that have been set would lead to such a cascading conflict.

4) Currently, Catalog -> By Category displays only the main version because labels are automatically cascaded, while a view such as Catalog-> By Rating may display multiple versions, since ratings are *not* automatically cascaded. I think the display logic may get a bit tricky if only some placeholders get cascaded info. (Ideally, those should be "collapsed" by default in the corresponding view.) And, with the risk of (re)opening a can of worms, I would say the proper answer to that might be provided only if FR #2525 (selectable style of display w.r.t. version sets) is implemented too. (Fortunately, some practical proposals were made there too - you could see them summarized in my last ticket note.)

...I'll keep the can of worms closed for now, but yes, it would help to implement something to address that request in parallel with this...

[Hert]

1) I would suggest catalog labels should be included in the cascading settings too (unless that makes the versioning logic too complex).

Yes, you're right - labels should be included too. I'll update the mock-up at some point. I'm thinking that there may be other things missing too - like the contents of the Details panel...

Catalog Labels should not be included in your design. Catalog Labels always apply to the full set (they are also not "auto cascaded" though i understand that it could be interpreted like that).

2) IIUC, the checkmarks for a placeholder would say that the respective kinds of info should be cascaded *to* that placeholder, right? Would the cascading source always be the main version or could it be any version? In the second case, I think there may be some potential for confusion; let's say that (V1, V2, V3) belong to the same set, with the cascading of ratings checkmarked in V3 only. If V1 gets 2 stars and V2 gets 4 stars and both images get synced, which star rating should V3 get? (Please don't say 3 stars... )

3) The same image may have multiple placeholders. In this case, would the cascading checkmarks be combined via OR (meaning: the info is cascaded if at least one assigned placeholder requests that) or via AND (meaning: the info is cascaded only if all placeholders request that)?

When these are included in your design, I think it will become more complex making it less accessible for the average John Doe. Beware for that pitfall. Don't try to cover everything in your UI...you could end up with something so complex that hardly anyone (read: only the 0.1% users who visit here) can use it but not the big group who could greatly benefit from a simple design covering 80% of the possibilities.

[fbungarz]

Hi Mke & Vlad,
reading your comments I am getting a bit worried that this "auto-cascade" feature request is getting a bit to complex. If we are asking for too much, it likely will never become reality...
For now I would vote to keep it simple. Color labels are already and always were assigned to all images. I would already be very happy if "auto-cascade" simply means this applies to all other data too.

Here my concerns:

Yes, you're right - labels should be included too. I'll update the mock-up at some point. I'm thinking that there may be other things missing too - like the contents of the Details panel...

Although it would be useful to have that option it would make the way large catalogs very complex. Imagine you have a deeply nested hierarchy. Would you have to select each label in that hierarchy and decide if it should be auto-cascaded? Or: would you select the parent not to be auto-cascaded and that setting applies to all children?
Also: if you have auto-cascading enabled in general preferences, would you then have to disable the labels that should not cascade?
I am not saying the feature is not useful, but it is asking a bit much. It adds a lot of complexity to what otherwise would be a relatively simple feature request. Given Hert's reluctance to overwhelm PSU with too much complexity it is likely auto-cascading will never be implemented if we ask for too many "bells & whistles"...
I think it would perhaps be wise to split this off into a separate feature request, asking for it once the general auto-cascading has been implemented.

For the same reason I would actually per default not include face or area tagging to be auto-cascades. This request again adds an significant challenge: in cropped or otherwise edited versions areas do not necessarily overlap with the main version (I read the thread about that topic and know there may be ways to circumvent this problem, but again: I am not against it, I am only cautious. If we want auto-cascading being implemented fairly soon, we should keep the request fairly simple).

I was thinking that everything should be cascaded from the main version, for simplicity.

I agree. For simplicity this makes the most sense.
[However, one could also a different implementation: combine auto-cascade it with auto-sync. In that case: you assign a label, xmp, GPS data, color labes etc. etc. and the info is automatically synced to all versions not only the one the data has been assigned too. This essentially would not be a true auto-cascade, but an enhancement how syncing works.
I am not sure though if this would work also with using a sync-queue, i.e., if auto-sync is switched off. In that case assigning labels to different versions and then sync that information could perhaps cause a conflict (the same label assigned twice to different versions and thus being removed, when it is assigned the second time). But then, these conflicts can possibly avoided if syncing keeps track of the sequence that labels/metadata are assigned.]

...would the cascading checkmarks be combined via OR via AND?

Thinking about this again I probably need to revise my last, very enthusiastic comments about the screenshot mockup. Coming from IDI, where assigning multiple images to one placeholder is not possible I had not thought properly about the complexity that deciding this option might cause. It would not be a problem with a brand new catalog, but it could wreck havoc if enabled in a catalog where information that is already present in different images is quite different...
So this is again turning into a more complex feature request if we are asking for auto-cascade with the option to select for which particular the placeholders this feature should apply.
For the sake of simplicity things would be much easier if there are two options only:
(1) auto-cascade "off" (default, the way how PSU currently works)
(2) auto-cascade "on" (all data except area/face tags cascaded to ALL versions)

Perhaps permitting a choice to selectively enable auto-cascade individually for the different categories of data still make sense. So, perhaps a user would want that his ratings are not automatically assigned to all versions, but prefer that all keywords/labels and XMP metadata are. That user would have the choice to not enable auto-cascade for ratings, but enable it for keywords/labels and XMP...

Again: all these ideas are relevant and it would be fantastic if they were implemented, but my personal order of priority would be:
(1) auto-cascade everything
(2) add an option to select which data is auto-cascaded
(3) add an option to select which to version data is auto-cascaded
(4) add an option to select to configure labels individually for auto-cascading

One and two could probably added fairly soon, three and four add a lot of complexity - with the chance that users will be overwhelmed, this Hert might want to avoid.

Currently, Catalog -> By Category displays only the main version...

Yes the ramifications of this are indeed a "can of worms". Again, implementing "auto-cascade" step by step might have the advantage that the feature could be introduced, tested and improved; issues that arise thus more easily be resolved.

Perhaps we should, at this stage not ask for too much?

Cheers,
Frank

[vlad]

Hert, thank you very much for your feedback. It's very good you made a clear statement on catalog labels, as that probably removes needless discussions. (I was suggesting their inclusion simply for completeness, and only on the condition that this would not have complex ramifications - but it probably would.)

I completely agree that we ought to suggest realistic proposals that work for the big group. Btw, I am also in that group w.r.t. versioning: I personally don't need auto-cascading specified by placeholder - I was simply analyzing Mke's proposal, on the understanding that such a granularity could be useful for him (and others). Heck, I personally don't even need granularity per different metadata kinds (but I'm pretty sure others do, that's why I included that in my request). Today I would probably choose to auto-cascade everything, if possible.

[vlad]

Frank, I've just seen your long reply and I mostly agree with your thoughts. Just a couple of specific comments:

Hi Mke & Vlad,
reading your comments I am getting a bit worried that this "auto-cascade" feature request is getting a bit to complex.

I think it's getting too complex only if catalog labels (and, possibly, placeholder settings) are considered.

If we are asking for too much, it likely will never become reality...

That's one very real possibility. Another one is that Hert is going to ignore whatever we dream up and come up with another (clear and clever) design altogether

For now I would vote to keep it simple.

+1

Color labels are already and always were assigned to all images. I would already be very happy if "auto-cascade" simply means this applies to all other data too.

Me too, but I'm not sure about others (Mke?). Also, I think it's fairly intuitive to have a symmetry between the manual and the automatic options.

Yes, you're right - labels should be included too. I'll update the mock-up at some point. I'm thinking that there may be other things missing too - like the contents of the Details panel...

Although it would be useful to have that option it would make the way large catalogs very complex. Imagine you have a deeply nested hierarchy. Would you have to select each label in that hierarchy and decide if it should be auto-cascaded? Or: would you select the parent not to be auto-cascaded and that setting applies to all children?

Oh, no!... Just for the record: I wasn't even remotely suggesting cascading options per label (that would be a nightmare, indeed!) but simply an option whether to cascade or not all (assigned) labels.

For the same reason I would actually per default not include face or area tagging to be auto-cascades.

+1

I was thinking that everything should be cascaded from the main version, for simplicity.

I agree. For simplicity this makes the most sense.

+1

[However, one could also a different implementation: combine auto-cascade it with auto-sync. In that case: you assign a label, xmp, GPS data, color labes etc. etc. and the info is automatically synced to all versions not only the one the data has been assigned too. This essentially would not be a true auto-cascade, but an enhancement how syncing works.
I am not sure though if this would work also with using a sync-queue, i.e., if auto-sync is switched off. In that case assigning labels to different versions and then sync that information could perhaps cause a conflict (the same label assigned twice to different versions and thus being removed, when it is assigned the second time). But then, these conflicts can possibly avoided if syncing keeps track of the sequence that labels/metadata are assigned.]

Frank, you're overthinking this way too much. First, let's forget about catalog labels: Hert has made that clear. Second, I would say (auto)cascading should either happen automatically (whenever that makes sense) or be triggered by write-syncing (whether manual or automatic). I think the general contract at the user level ought to be clear: if the main version is in-sync, then its (catalog) metadata is guaranteed to be mirrored across the version set, according to the auto-cascading settings.

So this is again turning into a more complex feature request if we are asking for auto-cascade with the option to select for which particular the placeholders this feature should apply.

I kind of agree.

For the sake of simplicity things would be much easier if there are two options only:
(1) auto-cascade "off" (default, the way how PSU currently works)
(2) auto-cascade "on" (all data except area/face tags cascaded to ALL versions)

Yep, that would be the most simple design.

Perhaps permitting a choice to selectively enable auto-cascade individually for the different categories of data still make sense. So, perhaps a user would want that his ratings are not automatically assigned to all versions, but prefer that all keywords/labels and XMP metadata are. That user would have the choice to not enable auto-cascade for ratings, but enable it for keywords/labels and XMP...

Again: let's forget about cascading keywords/labels. (If needed, we could request it again for Photo Supreme 5 or 6 ) However, we must still think about label mappings and detail profiles: the metadata changes triggered by those ought to be auto-cascaded as per the metadata cascading options. If that somehow poses any significant issue for the user model (or even the underlying design), then I would say we'd better drop per-category settings. Personally, I wouldn't endorse an implementation that ignores the label mappings or profiles. (But, perhaps, that's not a real concern if auto-cascading always happens after updating and syncing the main versions.)

Again: all these ideas are relevant and it would be fantastic if they were implemented, but my personal order of priority would be:
(1) auto-cascade everything
(2) add an option to select which data is auto-cascaded
(3) add an option to select which to version data is auto-cascaded
(4) add an option to select to configure labels individually for auto-cascading

I am in complete agreement with the priority order for (1)-(3) and completely opposed to any cascading option for individual labels. (Sorry if I inadvertently caused confusion and commotion with my original comment on catalog labels.)

Perhaps we should, at this stage not ask for too much?

That sounds like a wise suggestion.

[Mke]

Catalog Labels should not be included in your design. Catalog Labels always apply to the full set (they are also not "auto cascaded" though i understand that it could be interpreted like that).

Hert, thanks for your feedback
(Though personally I'd choose not have keywords written to web versions...)

Coming from IDI, where assigning multiple images to one placeholder is not possible...

Personally I wouldn't want to assign a version to more than one placeholder. And if you were wanting to auto-cascade differently by placeholder, then I imagine that you would refrain from assigning an image to two conflicting placeholders. However it would still be wise to have something in place to handle the situation should someone create a conflict.

Color labels are already and always were assigned to all images.

No they're not - they are assigned per version. At least that's the way they're working on my PC...

Again: all these ideas are relevant and it would be fantastic if they were implemented, but my personal order of priority would be:
(1) auto-cascade everything
(2) add an option to select which data is auto-cascaded
(3) add an option to select which to version data is auto-cascaded
(4) add an option to select to configure labels individually for auto-cascading

Well, I wouldn't disagree with your priorities from 1 to 3 - but if it's going to be added, maybe it would not be too complex to code for 3 from the start. But Hert, any of them would be good

[fbungarz]

No they're not - they are assigned per version. At least that's the way they're working on my PC...

Mhhhm - perhaps that is another difference between IDI and PSU then that I was not aware of

[Mike Buckley]

No they're not - they are assigned per version. At least that's the way they're working on my PC...

Mhhhm - perhaps that is another difference between IDI and PSU then that I was not aware of

PSU and IDimager work the same in that regard. For the seven years that I have been using IDimager first and then PSU, I have assigned one color label for one version, a different color label for a different version, etc., etc. In both programs, the user also has the option of assigning the same color label to all members of the version set.

[fbungarz]

In both programs, the user also has the option of assigning the same color label to all members of the version set.

Thanks for clarifying, I must have enabled that option years ago and forgotten about it.