version tab order and placeholders

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

version tab order and placeholders

Post by fbungarz » 30 Nov 16 11:15

Is there any reason why the tab order of the tiny tabs that denote versions are different ????

In the screenshot below, the print version is sometimes assigned to tab no. 1, then again tab no. 2 ...
VersionTabs.jpg
VersionTabs.jpg (98.83 KiB) Viewed 3127 times
This happens even though the version placeholders obviously have a certain per-configured sort order. In my case this:
VersionPlaceholder-Configuration.jpg
VersionPlaceholder-Configuration.jpg (54.81 KiB) Viewed 3127 times
I would expect the tiny tabs to be sorted the same way: Digital Negative = tab 1, Original = tab 2 and so forth... (if a particular version does not exist at least the sort order should remain the same!).

This is really inconvenient insofar as I would like to have my portfolios always to show the edited or print version of my files. Now, ideally this could be done easily using the filter menu, but: in Portfolios filtering versions is unfortunately not possible! This means the only option is to manually click on the little tabs (fortunately the portfolios remember these) - but since the print version is always on a different tab (!) one cannot even do this fairly quickly, but always has to check that the correct tab has been selected...
:(

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 30 Nov 16 14:35

Hi Frank,
fbungarz wrote:Is there any reason why the tab order of the tiny tabs that denote versions are different ????
I'm not a PSU developer, but I suspect there is a reason and it has to do with ease of implementation, as well as speed of (re)assigning the version tab numbers. (The version tabs would likely need to be renumbered, to ensure even half-predictable ordering in a number of scenarios.)

From a user perspective, I do understand your confusion and frustration, though.
This happens even though the version placeholders obviously have a certain per-configured sort order. In my case this:
VersionPlaceholder-Configuration.jpg
Well, that's the order of specifying placeholders in the global versioning preferences, but it doesn't necessarily match the order in which sub-versions are actually detected. Furthermore, the PSU doc (scarce as it is) does not mention any placeholder ordering. I do agree, though, that the design could be enhanced to take into account that particular ordering, although the pros and cons would need to be carefully sorted out.
I would expect the tiny tabs to be sorted the same way: Digital Negative = tab 1, Original = tab 2 and so forth... (if a particular version does not exist at least the sort order should remain the same!).
And what should happen if you remove DN from a version set? Will Original become tab 1? Then, if you add Digital Negative again, will Original shift back to tab 2? Such a design is certainly possible, but it would incur a performance overhead - and would still not ensure consistent numbering across all version sets, unless all images are versioned exactly the same.

I reckon that you've raised a valid issue, but I am now leaning towards giving up version tab numbers altogether, since they probably can't deliver any useful info or function (unlike placeholder icons). I have added a note to the relevant Mantis ticket: http://mantis.idimager.com/view.php?id=2964
This is really inconvenient insofar as I would like to have my portfolios always to show the edited or print version of my files. Now, ideally this could be done easily using the filter menu, but: in Portfolios filtering versions is unfortunately not possible! This means the only option is to manually click on the little tabs (fortunately the portfolios remember these) - but since the print version is always on a different tab (!) one cannot even do this fairly quickly, but always has to check that the correct tab has been selected...
:(
Yep, I could totally understand your frustration, although I would say that the inconsistent numbering only adds to the main pain: the impossibility to change multiple versions at once within a portfolio. (That capability shouldn't be implemented via version tab numbers, either.) Btw, is there a Mantis ticket for that enhancement request?

Regards,
Vlad

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 30 Nov 16 15:19

Hi Vlad,
I agree with most of your comments. Just some replies:

As I have tried to emphasize: I am by no means adamant that the tabs be numbered exactly according to their placeholder sequence. It simply would help already to have the sequence be consistent. Then it is irrelevant if you remove a particular version from the set. The sequence remains the same. Note that I am almost never using my B&W version, even though it is no. 4 in preferences, before print. It would not be a problem for me at all if the tab sequence would thus be "1 = Digital Negative - 2 = Original - 3 = Print"...

I do not agree that this may be a huge performance issue: I doubt anyone makes regular, fundamental changes to a huge amount of version sets. In fact, I hardly ever change the assignments, only ever add additional versions (B&W, print, edited) when I use external editors to generate these derivative files. So - PSu would hardly ever be forced to re-calculate sort order, simply add some more files and thus tabs according to the sequence specified in Preferences.
And I'd gladly pay the price of some minor performance hit if versioning was finally fixed!

Incidentally I wouldn't care much for the tab order if there was a quick way to simply display the version I want in a portfolio. The most straightforward way would be to allow the filters to work! I have no idea, why a dynamic search for versions in a portfolio would work, but a filter would not. It means, I have to create a dynamic search and add it as a new portfolio, delete the old one as a workaround or meticulously work my way through those tiny tabs...
Not intuitive at all.

Also: I have no clue why virtually any other filter works almost instantaneously, but filtering for specific versions is excruciatingly slow.

Your question if this has been even filed in Mantis? I don't think so. But there are many issues filed that pretty well illustrate that versioning is currently a bit of a pain, to just list the main issues (from my perspective): version detection during import ignores custom placeholders, even for automatic versioning it doesn't really work either, automatic placeholder assignments according to their file name masks are a bit of a gamble too: they essentially work only at random, placeholders are being removed when files are versioned a second time, filtering is sloooow and it does not work for portfolios...

Well, you yourself have filed many excellent suggestions. I just hope at least some of them will eventually be implemented. To me it appears implementing better versioning is currently not high on the list of priorities. Too bad, it means, if you want to use them (and I do) you are currently basically forced to use tons of workarounds.

Cheers,
Frank

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 30 Nov 16 16:38

fbungarz wrote: As I have tried to emphasize: I am by no means adamant that the tabs be numbered exactly according to their placeholder sequence. It simply would help already to have the sequence be consistent.
Well, here's the problem: you refer to a sequence simply because natural numbers (currently used for version tabs) do suggest a sequence. In effect, version sets have been designed as sets - that is, collections whose elements are unordered. (That design is sound, imho - it's the version tabs that don't quite fit with it.)

Let's ask ourselves: should we ever care about the odering of versions, or version tabs? Probably not: if you work on a collection and you have to click multiple tabs just to display a particular sub-version for a bunch of different images, then there's a design (ergonomy) problem right there! Therefore, what's really at stake for us, as users, is getting a fully functional interface: it should never force us to concentrate on minute details (version tabs) and have multiple clicks for multiple images, as a poor substitute for a logical, high-level operation on multiple images.
Then it is irrelevant if you remove a particular version from the set. The sequence remains the same. Note that I am almost never using my B&W version, even though it is no. 4 in preferences, before print. It would not be a problem for me at all if the tab sequence would thus be "1 = Digital Negative - 2 = Original - 3 = Print"...
Yes, but the moment you have a version set with a B&W version, the number 3 will suddenly mean something else, Print will get a different number, etc. Numbers are simply abstract symbols - unless you're a mathematician (and even then...), I can hardly imagine them being the proper designators for what are essentially non-numeric concepts and functions (ie, what does this version stand for? how do I quickly select my B&W version? etc.)
I do not agree that this may be a huge performance issue: I doubt anyone makes regular, fundamental changes to a huge amount of version sets.
You are probably right, but an internal sorting or renumbering would likely be required even during the initial version detection. (My hunch is that you currently see different tab numbers for different version sets because the file system functions called by PSU do not necessarily return file handles in a consistent order, relative to their location/name/extension; anyway, that's getting too technical for this forum...)
And I'd gladly pay the price of some minor performance hit if versioning was finally fixed!
Depends what you call "minor" and depends what you call "finally fixed" ;)
Incidentally I wouldn't care much for the tab order if there was a quick way to simply display the version I want in a portfolio.
Yes, exactly my point! (Think about it: the portfolio limitation is still a big pain even if you only have one sub-subversion.)
The most straightforward way would be to allow the filters to work! I have no idea, why a dynamic search for versions in a portfolio would work, but a filter would not.
How do you expect to use the filter in a portfolio?
It means, I have to create a dynamic search and add it as a new portfolio, delete the old one as a workaround or meticulously work my way through those tiny tabs...
Not intuitive at all.
I don't exactly understand your dynamic search workaround, but I certainly agree that you should never have to meticulously work your way through those tiny tabs, unless you want to pick different versions for different images.
To me it appears implementing better versioning is currently not high on the list of priorities.
It's hard to say, as Hert doesn't usually comment on priorities and he doesn't (transparently) assign ticket priorities in Mantis. Frankly, versioning is a cross-cutting feature (aspect) and it needs to be handled with care. I haven't been expecting any notable versioning changes (beyond bug fixes) in minor updates (PSU 3.x.y).

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 30 Nov 16 17:06

should we ever care about the odering of versions, or version tabs? Probably not
I don't think that is the point. As is, the version placeholders already get sorted.. Just chose: Catalog - By Version Placeholders. Same order as in Preferences.

I think having some pre-defined sort order is useful in any case. Showing the icons on the tabs is much better than meaningless numbers, but having these icons be sorted would still be a lot more convenient. Always having to check the icons is not too convenient either. I do not even care how the placeholders are being sorted - as long as it is consistent.
Depends what you call "minor" and depends what you call "finally fixed"
No, actually, it doesn't.
Minor means: minor, i.e., the program doesn't stall, doesn't hang, is simply a bit slower.
Finally fixed means:
(1) placeholders being recognized according to the file name masks specified in Preferences
(2) placeholder assignments not lost when adding a version
(3) quick filters for versions
(4) possibility to filter for versions in the portfolios

All these I personally consider to bugs. Hert would argue (3) & (4) are feature requests. He even suggested (1) is not meant to work during import.
I would respectfully disagree:
Portfolios are collections of images for a specific purpose. Versions are by design for specific purposes (a web version, a print version, an email version - all that are specific purposes). So in my opinion it completely defies what portfolios/collections are actually designed for, if one cannot easily include a particular version.

What do I mean by filtering, simple: click the filter button - select main version - all main versions are displayed; click the filter - select print version - all print versions are displayed. Works elsewhere throughout the catalog, does not work in portfolios.

Workaround: add version placeholder to dynamic search - add portfolio to dynamic search - execute the search - create new collection - add dynamic search results via right-click menu (drag & drop erroneously will only create a portfolio collection with the main version, not the specific version included in dynamic search).

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 30 Nov 16 17:44

fbungarz wrote:
Depends what you call "minor" and depends what you call "finally fixed"
No, actually, it doesn't.
Yes, it does:
Finally fixed means:
(1) placeholders being recognized according to the file name masks specified in Preferences
(2) placeholder assignments not lost when adding a version
(3) quick filters for versions
(4) possibility to filter for versions in the portfolios

All these I personally consider to bugs. Hert would argue (3) & (4) are feature requests. He even suggested (1) is not meant to work during import.
As the application designer, Hert might know better ;)

Think about it: if (1) was indeed designed to work during import, what would be the meaning of the import wizard rules under "Apply versioning"? (They could conflict with the global preferences.) I do agree there's potential for improvement there, but that deserves a seperate discussion.
Portfolios are collections of images for a specific purpose. Versions are by design for specific purposes (a web version, a print version, an email version - all that are specific purposes). So in my opinion it completely defies what portfolios/collections are actually designed for, if one cannot easily include a particular version.
I can agree with that.
What do I mean by filtering, simple: click the filter button - select main version - all main versions are displayed; click the filter - select print version - all print versions are displayed.

How do you select the main version filter? (I don't see it.)
Works elsewhere throughout the catalog, does not work in portfolios.
Fwiw, my filter scripts for versions work correctly in portfolios too. (You could use them to display only the main versions, although you can't probably use them to display only one particular sub-version out of many.)

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 30 Nov 16 17:55

Think about it: if (1) was indeed designed to work during import, what would be the meaning of the import wizard rules under "Apply versioning"?
Not sure I understand what you are suggesting: If you check "apply versioning" during import one might reasonably assume that it does what it says: apply versions! It does not! I versions the files but it does not apply their placeholders as defined in global preferences.
As far as I am concerned: during import your choice to assign placeholders to the main version no sense. Why would you assign a placeholder to the main version?

Here a screenshot of my filters:
Filtermenu.jpg
Filtermenu.jpg (68.79 KiB) Viewed 3076 times

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 30 Nov 16 18:52

fbungarz wrote: Not sure I understand what you are suggesting: If you check "apply versioning" during import one might reasonably assume that it does what it says: apply versions!
Fair enough.
It does not! It versions the files but it does not apply their placeholders as defined in global preferences.
The importing does apply versioning - the only room for discussion is if it does that correctly or not. And my point is that it's not unusual that the importer applies the import wizard rules rather than the global preference rules. (Under which circumstances would you expect the import wizard rules, rather than the global rules, to be applied?)

The main problem is that the import versioning rules are limited in comparison with the global versioning rules. (NB: that's a design issue, not an implementation issue.)
As far as I am concerned: during import your choice to assign placeholders to the main version no sense. Why would you assign a placeholder to the main version?
Sorry, but I don't understand your previous remark and ensuing question.
Here a screenshot of my filters: Filtermenu.jpg
Filter Main Versions is a script, right? (I don't have it.)

Regarding sub-version filters (eg, Raw Files), I've noticed that the behaviour differs based on a peculiar detail:
a) If the portfolio collection is selected in the catalog browser by clicking on the collection name or next to it, then applying the filter has the effect that no image is displayed at all.
b) If the portfolio collection is selected by clicking on the imager counter to the right, then applying the filter displays all versions matching the filter - but that includes versions that do not actually belong to the portfolios. (Only their main versions do.)

Frank, can you replicate my finding?

(In my view, neither behaviour is correct - I'm disappointed but not that surprised. Sadly, I've always found versioning and type filters to be flawed - and that's not limited to portfolio collections in particular.)

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 01 Dec 16 9:37

Hi Vlad,
sorry for not getting back yesterday anymore.

To out it more simple:
From my perspective it does not make sense to have different settings for version detection during import and during regular version detection (SHIFT+CTRL+V).
During import you can define which image becomes your main version, all others become subversions. The main version per definition does not have a placeholder assigned, so why the option to select one? That does not make sense to me.

Placeholders are, by design, relevant for subversions only. They denote the purpose of these subversions. The subversions receive their placeholders according to the file name masks specified in Preferences [theoretically, if that assignment procedure actually worked correctly during regular version detection SHIFT+CTRL+V; it doesn't - existing placeholder are being removed, only the new ones are assigned!].
Now, you could argue, fine, why would it be necessary for the importer to also recognize these derivative subversions? Well, because it is an Importer, not only a Downloader. It can be used not only to download files straight from the camera, but also to import existing files that were previously managed perhaps in another PSu database (.e., where versions already had been assigned). Likewise, the "verify folder" command should correctly recognize versions, currently it removes existing placeholder assignments and only assigns a placeholder for the most recent addition.

Now - an additional argument: why would anyone need the option to configure import version detection settings differently from global settings??? The purpose of having global settings is to have them applied globally! In which kind of scenario would it actually be useful to import files and have them being versioned according to one versioning rule and subsequently use version detection on these files that destroys the previous import assignments because it follows different rules specified in Preferences? To me this does simply not make sense. All you do is creating a system that is both unintuitive to the user and will almost per default create conflicting results. It is a system that is design to fail, to make versioning unnecessarily complicated.

I'd be quite happy to accept the way things work and resign myself to haveing to use workarounds, if someone can explain to me a reasonable scenario where you would regularly need to have the importer be configured differently from your global versioning preferences. For now I cannot see such a necessity.

In summary - it simply does not make sense to have the Importer work differently, have its own configuration options for versioning.

Regarding your comment:
I've noticed that the behaviour differs based on a peculiar detail
This is very interesting. At first I thought you had found me a option to actually get my filters to work even in portfolios. If you click the numbers, the main version actually gets displayed in a portfolio, not the subversion that you selected to be displayed there. I thought: great, this means that I now can use the filters. No, does not work. In both views only one single version is included in the portfolio, so any filters to return a particular subversion cannot work. How do I know that: my main version and print versions are both JPGs, the original version is always a NEF, the digital negative version a DNG. If I try to filter a portfolio for file type, it always says JPG only, the NEFs and DNGs are not included. That, incidentally, is different for labels, were you have all versions from a set.

I am starting to wonder, what portfolios and collections are actually good for. It would probably be much more convenient to simply create a label category called "portfolios" and replicate the portfolio structure there. Then I would not be limited to the restrictions of portfolios, could easily filter the files. Perhaps that's the way to go. Since they are so restrictive, simply abandon the whole idea of portfolios. Ideally, I would much prefer them to gain more versatility, become more useful, more powerful. I also like the idea that they are separate from the main catalog. But it does not seem that the various suggestion how to make them more useful will be implemented any time soon...

Cheers,
Frank

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 01 Dec 16 13:40

Hi Frank,
fbungarz wrote: From my perspective it does not make sense to have different settings for version detection during import and during regular version detection (SHIFT+CTRL+V).
Perhaps you're right, perhaps not. (See bellow.)
During import you can define which image becomes your main version, all others become subversions. The main version per definition does not have a placeholder assigned, so why the option to select one? That does not make sense to me.
Sure, but the placeholder option within the import wizard refers to sub-versions rather then main versions. (That said, I agree that the wording and the tip for the versioning settings ought to be improved. Not to mention the bigger problem: the importer's (legacy) assumption that versioning always implies just JPG-RAW pairs.)
The subversions receive their placeholders according to the file name masks specified in Preferences
Yes, but that happens (by design) only for the versioning performed during regular cataloguing. It is not meant to happen for the versioning performed during importing. (Otherwise, the Placeholder setting in the import wizard would need to be ignored, right?) I do agree that the current design is confusing and limiting.
[theoretically, if that assignment procedure actually worked correctly during regular version detection SHIFT+CTRL+V; it doesn't - existing placeholder are being removed, only the new ones are assigned!].
That could be a bug, although I don't quite understand your use case: are your Shift+Ctrl+V input images versioned or not? Do you simply want to add new sub-versions to an existing version set? In that case, was your existing version set created during importing?
Now, you could argue, fine, why would it be necessary for the importer to also recognize these derivative subversions? Well, because it is an Importer, not only a Downloader. It can be used not only to download files straight from the camera, but also to import existing files that were previously managed perhaps in another PSu database (.e., where versions already had been assigned).
Yes, I agree that the importer is too limiting in its assumptions.
Likewise, the "verify folder" command should correctly recognize versions, currently it removes existing placeholder assignments and only assigns a placeholder for the most recent addition.
Again, that could be a bug. Did you report it?
Now - an additional argument: why would anyone need the option to configure import version detection settings differently from global settings??? The purpose of having global settings is to have them applied globally! In which kind of scenario would it actually be useful to import files and have them being versioned according to one versioning rule and subsequently use version detection on these files that destroys the previous import assignments because it follows different rules specified in Preferences? To me this does simply not make sense.
That, I don't know. The import wizard design is very powerful, as it allows multiple profiles, with completely different settings for different import sessions. Do you agree that some power users need that kind of flexibility? To me, it seems somewhat arbitrary to remove import profile flexibility (only) for version settings.

Fortunately, I have a simple proposal which would achieve exactly what you want, without removing any flexibility (should one need it):

In the import wizard, a dropdown could be added under Apply Versioning, with the following two options:
  • Apply versioning rules specified in the global preferences
    Apply specific versioning rules
If the first option is selected, then the importer will apply the very same rules as for Shift+Ctrl+V. (Just what you want, Frank!) If the second option is selected, then the importer will offer and apply specific rules (per profile), just like today. (In addition, the specifc rules could be enhanced with custom filemasks, à la global preferences, to possibly account for arbitrary tuples rather than the simple case of JPG-RAW pairs.)

Wouldn't that work for everyone, with the bonus that existing import profiles could be made forward compatible with the proposed design change?
All you do is creating a system that is both unintuitive to the user and will almost per default create conflicting results. It is a system that is design to fail, to make versioning unnecessarily complicated.
I understand your reasoning, but I'm not yet sure I buy it. Let's see: for a given import session, potential conflicts could arise only if the currently imported files were also checked against previously imported files. My understanding, however, is that such checks are not performed (see here). If I am right, that (reasonable?) limitation prevents possible conflicts. (Sure, you could still get conflicts when you mix files from different import sessions, but that's like saying that you could get naming conflicts if you employ different renaming rules.)

The good news is that it's not an either-or issue: my proposal would add new flexibility, without taking away any.
I'd be quite happy to accept the way things work and resign myself to haveing to use workarounds, if someone can explain to me a reasonable scenario where you would regularly need to have the importer be configured differently from your global versioning preferences. For now I cannot see such a necessity.
Also, it would be interesting to learn if someone reverts in practice to different configurations for different import sessions. (Hard to imagine, given the current limitation regarding JPG-RAW pairs.)
In summary - it simply does not make sense to have the Importer work differently, have its own configuration options for versioning.
Perhaps you're right, although an import profile is probably meant (by design) to encapsulate virtually all import settings. (Still, some global preferences, such as Synchronize Settings -> Read settings, are already applied too.)

If you click the numbers, the main version actually gets displayed in a portfolio, not the subversion that you selected to be displayed there.
Good point. But I think it's only a fluke - how could it be by design?
If I try to filter a portfolio for file type, it always says JPG only, the NEFs and DNGs are not included. That, incidentally, is different for labels, were you have all versions from a set.
Yeah, I myself had noticed such oddities in the past - I'm going to check if I reported them in Mantis.
I am starting to wonder, what portfolios and collections are actually good for.
Well, I think your main problems with portfolios are actually revolving around versioning issues - so that seems to be the common theme for virtually all your complaints ;)

Cheers,
Vlad

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 01 Dec 16 14:30

Hi Vlad,
Well, I think your main problems with portfolios are actually revolving around versioning issues - so that seems to be the common theme for virtually all your complaints
Couldn't agree more. Actually, I am a 99% satisfied customer, resolving the versioning issues is the remaining 1% :wink:
And: regarding the addition of native DwC support - I am actually 200% satisfied, you do the math :mrgreen:

[quote]Apply versioning rules specified in the global preferences
Apply specific versioning rules
[/quote]

I would most certainly not be opposed to having such an option. Only, I highly doubt it is even necessary. For simplicity's sake it would be much easier simply to always apply global preferences.

In my opinion the strict assumption that versioning during import only applies to JPG+RAW pairs is really the problem here. I think this is simply an unresolved leftover issue from integrating IDI's downloader and importer into one. In IDI you had the option to download virgin files (from a camera) and import existing folders. Those two were merged and the fact that the importer treats all files as if they can possibly exist only be versioned if they are pairs seems to be an anachronism, an unresolved leftover from the IDI epoch ...

Well, talking about all this with you made me realize quite another potential conflict, why I believe the current implementation is not only counter-intuitive, but could even be classified as a bug:
What happens if you read ICS during import AND have versioning enabled? What "versioning info" then gets applied? Which one has priority? Presumably we are being told ICS is meant to be a safeguard option that lets you re-create the catalog from embedded XMP. That would need to include versioning info, right?
So, if I have a JPG+NEF+DNG triplet as my version set "main+original+digital negative" (that's my default). What will happen to this triplet upon import if ICS from these files is being read AND I have versioning enabled?
That could be a bug, although I don't quite understand your use case: are your Shift+Ctrl+V input images versioned or not? Do you simply want to add new sub-versions to an existing version set? In that case, was your existing version set created during importing?
Since it does not work for me at all, I am not using versioning during import. That means I use Shift+Ctrl+V immediately after the import (and after I added the DNGs) to version my triplets of original files: JPG+NEF+DNG. But despite the placeholder file masks specified it is pretty much arbitrary whether the files are correctly recognized.
It definitely is a bug.More than a year ago yYou even wrote me a script to fix it, remember? The script checks if all DNGs to my "digital negative" placeholder and if all NEFs are assigned to my "original" placeholder - if it finds some that are not correctly assigned it assigns the placeholders...

Now the problem arises, if I use an external editor to generate a developed version of these files, say the print version. Using Verify Folders these files generated outside PSu are easily found.
BUT: if I use the checkbox in the verify dialog to add these files as a version, the other, existing placeholders are removed from the other versions. If I just have verify add the files and then use SHIFT+CTRL+V the result is the same: only the newly added version is assigned to the print placeholder, the other versioned files have their placeholders removed.

The bug reports filed date back to the time when I first started my IDI - PSu migration. They have never been resolved. Possibly because I back then really struggled with so many different issues all at once. Perhaps, now that I have a better understanding of what exactly is not working, I should file these issues again, explaining more precisely what does not work.

Cheers,
Frank
Last edited by fbungarz on 01 Dec 16 14:36, edited 1 time in total.

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 01 Dec 16 14:30

fbungarz wrote:If you click the numbers, the main version actually gets displayed in a portfolio, not the subversion that you selected to be displayed there.
I've tested this a bit further: the main version gets displayed only if the sub-version was manually selected in the portfolio (ie, by adding the main version and then clicking a version tab). If a sub-version was added to the portfolio by Shift+Ctrl+B or drag'n'drop, then it is still displayed as such when clicking the image counter.

Apparently, working with sub-versions in portfolios is shaky at best.

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 01 Dec 16 14:40

Apparently, working with sub-versions in portfolios is shaky at best.
Absolutely!
Another oddity: Via drag & drop you can only add the main version to a portfolio. Via the right-click menu (Shift+Ctrl+B) you can add a specific version too.
So, in my case I can filter the versions I want, then use Shift+Ctrl+B to add those specific versions to a portfolio. Using drag & drop this does not work, the main versions are added instead...

vlad
Posts: 895
Joined: 01 Sep 08 15:20

Re: version tab order and placeholders

Post by vlad » 01 Dec 16 15:02

fbungarz wrote: Couldn't agree more. Actually, I am a 99% satisfied customer, resolving the versioning issues is the remaining 1% :wink:
...Problem is: solving the remaining 1% often takes 99% of the time :)
In my opinion the strict assumption that versioning during import only applies to JPG+RAW pairs is really the problem here. I think this is simply an unresolved leftover issue from integrating IDI's downloader and importer into one. In IDI you had the option to download virgin files (from a camera) and import existing folders. Those two were merged and the fact that the importer treats all files as if they can possibly exist only be versioned if they are pairs seems to be an anachronism, an unresolved leftover from the IDI epoch ...
Agreed.
What happens if you read ICS during import AND have versioning enabled? What "versioning info" then gets applied? Which one has priority?
I don't know, but it's probably wise to turn off versioning (and virtually all fancy options) in those special cases where we have to import images with ICS reading enabled. (My expectation is that should still recreate the versioning info in the catalog.)
Presumably we are being told ICS is meant to be a safeguard option that lets you re-create the catalog from embedded XMP. That would need to include versioning info, right?
Right: IIRC, versioning info is indeed included in ICS, but I also recall your past report that it wasn't recreated correctly upon ICS reading. Maybe you could check again and submit a bug report, if needed.
Now the problem arises, if I use an external editor to generate a developed version of these files, say the print version. Using Verify Folders these files generated outside PSu are easily found.
BUT: if I use the checkbox in the verify dialog to add these files as a version, the other, existing placeholders are removed from the other versions. If I just have verify add the files and then use SHIFT+CTRL+V the result is the same: only the newly added version is assigned to the print placeholder, the other versioned files have their placeholders removed.
That's likely a bug, but it raises an interesting issue: if you created a version set based on some versioning rules and then run Shift+Ctrl+V on that set and a newly imported image, should all the placeholders be reassigned (as if versioning was applied all over again) or should only the new version get a placeholder?

As a practical workaround: couldn't you first destroy the old version set and then use Shift+Ctrl+V on the new selection? (Nah, I guess that won't work either if Shift+Ctrl+V is broken for custom filemasks.) What if you use Shift+V rather than Shift+Ctrl+V for a given image tuple - does that work correctly?

fbungarz
Posts: 1542
Joined: 08 Dec 06 5:03
Location: Arizona, USA

Re: version tab order and placeholders

Post by fbungarz » 01 Dec 16 15:14

if you created a version set based on some versioning rules and then run Shift+Ctrl+V on that set and a newly imported image, should all the placeholders be reassigned (as if versioning was applied all over again) or should only the new version get a placeholder?
A non-issue, really. All I care for: the existing placeholder assignments should not be removed, when a new version is added receiving its placeholder. How that internally is best achieved, if first placeholders are removed and then re-assigned, no idea. For the user perspective it won't make a difference. end result is the same: versioned files with correct placeholder assignments.
couldn't you first destroy the old version set and then use Shift+Ctrl+V on the new selection? (Nah, I guess that won't work either if Shift+Ctrl+V is broken for custom filemasks.)
You got it. Destroy & re-create is not an option, because correct placeholder assignment does not work anyway. But even if it did work - the most convenient way to add versions is via "verify". In a portfolio I typically deal with images from multiple folders...

Shift+V is not an option either. It versions ALL selected versions! I am not even sure what Shift+V is supposed to be used for. To me it is a completely redundant even "evil" option! It makes a mess of versions! Instead of detecting related files it just lumps everything together. It was a bit of a shock when I accidentially tried it once...

Anyway - I think there is definitely something very wrong with portfolios! In my case it seems filters generally don't work, not just the ones on versions. I now bookmarked a bunch of files and tried to filter for the bookmarked ones only; I get an "Access violation (0)" message, nothing works anymore, have to force-quit PSu via the task manager.
After restart I try filtering the bookmarked files again: they are not being returned. The filter returns no images! I invert the filter: both bookmarked and non-bookmarked images are returned.
As far as I can tell, this happens BTW if you selected specific versions to be included in your portfolio. It does not seem to be the case if you want to filter the main versions in a portfolio...

Post Reply