Different counts with filters
As we have found in another procedures which could help to speed up workflow, here another try.
One of the most annoying issues in Windows version are the different counts (displayed numbers) within filters. T show two examples:
You easily can see the difference: The catalog holds 19532 images but only 19522 can be selected.
394 images "wear" yellow color, only 390 are shown on the right side.
This issue I could see during the last years on ALL Windows PCs of ALL friends I could access easily. Phase One has approved this issue but did not do anything during the last years. If I remember right this was one of the issues they recognized but "did not know how to fix" (the original wording was lost with the old ticket portal). I can find this problem sometimes in (catalog) folders too but need more often selections out of all images (for books to special topics.
I did not find this issue an Macs but looked only at a few.
And now you can help - maybe. ;) What I could not get out:
- How to see which images are affected of this issue?
- How can I gather all this affected images (to solve the problem)?
Do anybody have an idea?
Could be just a missmatch of numbers or a counting error, then we cannot do anything. But I think its worth a try to ask you.
Kind regards
Ernst
-
Ernst,
If you have multiple variants for an image and both the current Primary variant (the one that will always display in the Browser) and others of the variants for the same image that also have the same filter selection criteria (in this case the Yellow colour tag) you may see an apparently mismatch in the numbers.
Change the Images to "Expand Selected" in the "Image" drop down menu to see all yellow tagged variants for that image.
If an image has several variants and only one of them (Not the current Primary variant) has a yellow tag then that variant will still be selected by the filter and shown in the browser.
This may seems a little odd at first but actually makes good sense and obeys the settings once one is familiar with the way it works. It is also quite useful to work this way since the apparent mismatch helps to identify that there are other variants that you might be interested to see even if you have already set at least one variants that satisfies the filter selection to be the Primary variant.
This concept should work for all filters and combinations of filters.
0 -
Hi SFA!
Great! Thanks a lot for thinking for me. ;) Phase One dis check over month - and nobody there came on the point.
Please, could you give me a screenshot of this part of your menu:
because the German translations say all and nothing? I would prefer "show all variants" with a checkmark before. Would make it clearer for me.
Your explanation is good for the most occurrences of this phenomenon. BUT:
Yesterday (not only but too) I had 94 red images. Red means "should be deleted physically from harddisk". As I selected all of the red images the number displayed in the right upper corner was 51. After deleting the number at this place dropped to none, in the filter area the number dropped to 43. And stayed for more than half an hour. Today morning it was zero again.
Any idea for this behaviour?
Kind regards
Ernst0 -
Sorry, just found the English menu. ;)
0 -
For your Red Deletion question I think, the answer may be almost the same as for the Yellow - at least in theory.
If you have multiple variants for an image with more than one variant tagged with Red the count of red tags will be higher than the number of files to be deleted.
The Red tag count is made at the variant level and is in effect Dynamic rather than a static count constantly updated in some sort of fully maintained master count field(s).
Deleting will remove the file and the counts related to fields in the currently selected "Primary" variant but, I suspect, not the other variants. This may be considered an oversight in the coding or simply a way of speeding up the process for files that are about to be deleted.
The dynamic count that will occur the next time the same filter is refreshed will reset the value to zero before counting and, if nothing if found, will remain as zero.
Forcing a refresh of the selection in some way would have the same effect.
I suppose there is some possibility that in some cases some of the tagged files cannot be deleted for some reason and so the count value could still be "genuine". But if the count is 0 after the next refresh then that would seem not to be the case.
It might be considered a small bug related to managing the dynamic count but I think the specific use case (delete from disk) may be one that user can feel comfortable enough to not worry about once the reason for the potential anomaly is understood and a means of refreshing the count (via an enforced refresh) if required as a comfort factor has been identified.
There may be other reasons but this would be my current suggestion. If you find a different situation we can think about it again and re-analyse what happens.
0 -
Hi SFA,
thanks for quick reply.
In the meanwhile I could see that your explanations work in most cases. But there are still bugs too.
First: Red images do not have variants. Variants are used by myself in only very few cases (if color plus SW or something like this) and regard one or two per thousand images. The found mismatch of numbers with red images cannot be justified with variants.
Second: I have found (in another procedure, I will later make a new thread for it) that trash can act a part in this game. I seems to be that images in the trash can are counted with - which never should be. If I empty the trash can the numbers change. It's rather possible to play around with this but I could see this behaviour in two different catalogs.
What I have found too was, that sometimes (I could not find any regularity) the expansion of variants does not affect the number in the upper right corner. Okay, you have to change and re-change the selection (refresh of the selection) to see a change of this number, but sometimes the number changes but doesn't match exactly until you restart C1. (I have screenshots a lot. If you need I can publish.)
Kind regards
Ernst0 -
Hi Ernst,
I think the Catalogue or Session trash still has to be counted as they are still active within the data base. They can, for example, still be recovered from trash. Indeed the "trash" folder is a virtual setting - you can make any system folder the trash folder for a current session for example - and so it potential usage is not exactly the same as the OS Trash folder.
On the more general count match/non match situation ... it can get complicated - especially if multiple filters are in place and even more especially if applying filters to something that is already a filter - like a smart album for example.
There may well be anomalies in the way that the live count numbers are maintained in "real time" - I could not claim any certain experience that there are no issues in that activity. However it is entirely possible to have a rather complex set of are circumstances that look like some sort of problem but in fact are not a problem. Indeed even some things that are possibly temporary dynamic count update issues but are lacking in any real operational relevance.
This is, after all, something we can see a lot in computer systems. Obvious examples include trying to order something where there seem to be stock available according to the system but none actually exists. Now that IS something with operational relevance! The probability is that the stock availability value is not a dynamic value but is based on a starting value form a physical count of some sort and will only ever be corrected by a physical count and reset. Dynamic counts of data records are easier to reset.
0 -
Hi SFA,
I appreciate your help!
> I think the Catalogue or Session trash still has to be counted as they are still active within the data base.
Let me agree - even if I do not like this behavior.
> On the more general count match/non match situation ... it can get complicated - especially if multiple filters are in place and even more especially if applying filters to something that is already a filter - like a smart album for example.
It IS complicated, indeed. Even if I do not use smart albums (I use only one: "Best Of" for all images with 4 and 5 star images).
> There may well be anomalies in the way that the live count numbers are maintained in "real time"...
Let me explain:
- Phase One support has got all datas from me.
- Phase One support has got screenshots and - in this case - even videos.
- Phase One support has got logs.
- Phase One support has got my whole database (and some images they needed) - with which they could recognize this issue - on a Windows PC. They first tried on a Mac and did not find any problem. I had to tell them several times to test on a Window machine as I use mostly Windows with catalogs.
- Phase One support did find the issue after month of discussions and confirmed as an issue.
- Phase One has not fixed it till today.
> This is, after all, something we can see a lot in computer systems.
Yes, you are quite right. We can find problems on other software too. In most of the cases they are fixed in one of the next updates. But to see that something else is bad - does this better anything?
Consider there are a lot more serious problems in Capture One. Not all come up with every user. Even seeing and agreeing that C1 is complicated software it should work halfway stable under Windows like under Mac. And this is the point: Most of issues I have to work with are not existent on a Mac (where I work too but not so much).
Sounds as I do not recognize the advantages and benefits of Capture One. This is wrong, I do. And I even recommend Capture One in my posts and in my blog posts. But I can see problems too even when loving Capture One.
Thanks again, SFA: You helped me a lot to understand. Really. Based on your explanations I lost most of the fear to loose images during working with Capture One. This is a lot of help for this short thread! ;) And it is a big step forward for me.
Kind regards
Ernst0
投稿コメントは受け付けていません。
コメント
7件のコメント