Hello,
It could be useful to have the number of images inside each album displayed after the album name
This post is related to viewtopic.php?p=174338#p174338
Thanks for listening
album feature request : number of images
Moderators: XnTriq, helmut, xnview
-
- Posts: 304
- Joined: Mon Apr 06, 2020 2:06 am
- Location: Martinique
-
- XnThusiast
- Posts: 1955
- Joined: Sat May 09, 2015 9:37 am
Re: album feature request : number of images
+1
it would be nice to have counters for:
- rating
- color labes
it would be nice to have counters for:
- rating
- color labes
-
- XnThusiast
- Posts: 1676
- Joined: Wed Aug 16, 2006 6:31 am
Re: album feature request : number of images
Trickier to do for Albums because for many albums and many photos it can be slow.
It is much better to implement it through RMB menu on the root node of each group - that is „Rating”, „Color” and „Albums”. We need a decisive action from the user's part in order to display them.
Here the problem is that it isn't discoverable, but a tooltip can fix that.
It is much better to implement it through RMB menu on the root node of each group - that is „Rating”, „Color” and „Albums”. We need a decisive action from the user's part in order to display them.
Here the problem is that it isn't discoverable, but a tooltip can fix that.
m. Th.
- Dark Themed XnViewMP 1.7.1 64bit on Win11 x64 -
- Dark Themed XnViewMP 1.7.1 64bit on Win11 x64 -
-
- XnThusiast
- Posts: 1955
- Joined: Sat May 09, 2015 9:37 am
Re: album feature request : number of images
this is ridiculously unusable approachm.Th. wrote: ↑Sun Nov 19, 2023 6:23 pm It is much better to implement it through RMB menu on the root node of each group - that is „Rating”, „Color” and „Albums”. We need a decisive action from the user's part in order to display them.
Here the problem is that it isn't discoverable, but a tooltip can fix that.
it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..
-
- XnThusiast
- Posts: 1676
- Joined: Wed Aug 16, 2006 6:31 am
Re: album feature request : number of images
It is not magic. I have been a DB/UX programmer for more than 30 years now. It is an aggregate SQL query on DB and knowing exactly the underlying DB schema on both XnView and Lr, I know what I am saying. Do you know?it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..
At startup, DB/computer is hammered by a lot of requests especially because of the Thumbnails engine/browser. Parallelization here actually can make the things slower than faster, if we are talking about enough queries and data.
Bad Lr design decisions hinder the size of catalogs which is also a common problem for Lr.
Deferring the queries over DB is the way to go IMHO.
Harsh words. Care to explain?this is ridiculously unusable approach
m. Th.
- Dark Themed XnViewMP 1.7.1 64bit on Win11 x64 -
- Dark Themed XnViewMP 1.7.1 64bit on Win11 x64 -
-
- XnThusiast
- Posts: 1955
- Joined: Sat May 09, 2015 9:37 am
Re: album feature request : number of images
rly? hope you're a better db than UX "programmer".m.Th. wrote: ↑Sun Nov 19, 2023 7:48 pmIt is not magic. I have been a DB/UX programmer for more than 30 years now. It is an aggregate SQL query on DB and knowing exactly the underlying DB schema on both XnView and Lr, I know what I am saying. Do you know?it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..
You know some words for sure.. schema, lol, I would worry about indexes more
Code: Select all
XnView.db
SELECT albumid, COUNT(*) FROM albumslink
SELECT rating, COUNT(*) FROM images GROUP BY rating
SELECT color, COUNT(*) FROM images GROUP BY color
I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.
You're missing the point.m.Th. wrote: ↑Sun Nov 19, 2023 7:48 pm At startup, DB/computer is hammered by a lot of requests especially because of the Thumbnails engine/browser. Parallelization here actually can make the things slower than faster, if we are talking about enough queries and data.
Deferring the queries over DB is the way to go IMHO.
I'm not talking about multiple simultaneous queries at "startup time".
App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
When data is ready, it will be shown in counters.
If user is lightspeed fast and clicks on any filter while some counters are pending, their execution is delayed until user's request is completed.
Explain why clicking on every Rating/Color/Album to check its counter is bad idea?
Well, it is clumsy, time consuming, non informative.. against main purpose of such counters - to show big picture.
It is obvious as day.
Wonder why it is ok with your "design principles" of >30years in "UX programming", whatever it means.
Again, this is not something uncommon, there are image organizers that have catalog counters and it just works.
-
- XnThusiast
- Posts: 1676
- Joined: Wed Aug 16, 2006 6:31 am
Re: album feature request : number of images
Sorry, but you are overly aggressive. I still expect some links from you about UX principles WRT Lr, but besides that, it isn't appropriate to make continuous attacks „ad hominem”.rly? hope you're a better db than UX "programmer".
The first one is problematic because in albumslink table is a m:n relationship which in some cases will explode the table's cardinality.now tell me what number of records will cause execution time of these 3 queries to be slow, eg >few seconds
Even „few seconds” is problematic because, as I said, at startup time there is a lot of work going there. Besides that, the maintenance of such statistics during the session can be problematic, if the scanning thread which generates the thumbnails in a new folder reads from a source (eg. XMP) data about Ratings/Colors and (perhaps) albums.
The main selling point of XnView MP is its speed - unlike Lr which has a slow import procedure.
You must understand that the two aren't in the same market and it is wrong to try to make XnView MP „yet another Lr”. This will never be. There are ENOUGH programs (much more mature than XnView MP) (some of them are free) which try to mimic Lr.
Sorry, but your solution is flawed because many users - including myself - have Filter Catalog open & visible at startup.You're missing the point.
I'm not talking about multiple simultaneous queries at "startup time".
App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
yes. Thinking that your user case is the only one. Is not. I am not complaining also about this, but this issue is (was?) a common one in communities.I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.
Besides that, 100k files is a LOW number of files.
FYI, statistically speaking a wedding photographer shoots ~100k photos / year. Usually, there are two of them. A sports photographer shots even more/year (especially if we have a major sports event in his/her field). A war/crisis photographer even more (depending on assignment).
However, the most important part is (again) XnView MP is very different than Lightroom. Lr is NOT a multimedia file browser. You NEED to do an „Import” there in order to work with the files.
In XnView MP every folder you look at, it gets scanned and, so, the DB grows much more quicker than in the case of Lr.
One of the main use cases of XnView MP is to quickly have the files on the SSD, select/tag them - Batch Convert them (it has the fastest Batch Conversion engine for professional news photographers AFAIK - yes, I searched) and publish them.
I didn't say this. Re-read, please. I said „on the root of each group”. That is on the nodes labeled „Rating”, „Colour Label”, „Album”.Explain why clicking on every Rating/Color/Album to check its counter is bad idea?
Which is the main purpose in your opinion and how often do you look at them? (especially at the counter(s) of (an) album(s))against main purpose of such counters
m. Th.
- Dark Themed XnViewMP 1.7.1 64bit on Win11 x64 -
- Dark Themed XnViewMP 1.7.1 64bit on Win11 x64 -
-
- XnThusiast
- Posts: 1955
- Joined: Sat May 09, 2015 9:37 am
Re: album feature request : number of images
I encourage you to go and re-read mentioned topic, starting from your offtop about app design/speed/bug that ended up with Photoshop-PowerPoint comparison. I have nothing to add there.
Speaking about db, I've checked your proposal to create mess by mixing metadata into m1 and m2 tables.
So yes, I'm a little skeptical about your competence.
There are UNIQUE("AlbumID","ImageID") constraint and cascade deletion. What "some cases will explode the table's cardinality" are you talking about.
I also thought you'd notice that 1st query will not work without grouping....
Code: Select all
SELECT albumid, COUNT(*) FROM albumslink GROUP BY albumid
you didn't quote the whole paragraph on purpose, did you?m.Th. wrote: ↑Wed Nov 22, 2023 9:10 amSorry, but your solution is flawed because many users - including myself - have Filter Catalog open & visible at startup.You're missing the point.
I'm not talking about multiple simultaneous queries at "startup time".
App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
user0 wrote: ↑Mon Nov 20, 2023 7:39 am App has to update Catalog counters only when you open Filter Catalog tab, in non GUI blocking thread.
When data is ready, it will be shown in counters.
If user is lightspeed fast and clicks on any filter while some counters are pending, their execution is delayed until user's request is completed.
Google says people have no issues with 1M photos in catalog of current Lr. Those who complain about "CatAlOg SiZe" don't realize that there are many other things that can slow down Lr.m.Th. wrote: ↑Wed Nov 22, 2023 9:10 amyes. Thinking that your user case is the only one. Is not. I am not complaining also about this, but this issue is (was?) a common one in communities.I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.
Besides that, 100k files is a LOW number of files.
FYI, statistically speaking a wedding photographer shoots ~100k photos / year. Usually, there are two of them. A sports photographer shots even more/year (especially if we have a major sports event in his/her field). A war/crisis photographer even more (depending on assignment).
However, for pro use it does not matter how many photos you have per year, since at some point you have to use multiple catalogs anyway, so just use them per client/project.
If you have personal issues with Lightroom - there is (mentioned already) CaptureOne that has counters as well.
Thats the issue, a) there shall be option to switch off auto-import and b) Catalog shall be browsable.m.Th. wrote: ↑Wed Nov 22, 2023 9:10 am However, the most important part is (again) XnView MP is very different than Lightroom. Lr is NOT a multimedia file browser. You NEED to do an „Import” there in order to work with the files.
In XnView MP every folder you look at, it gets scanned and, so, the DB grows much more quicker than in the case of Lr.
Manual import adds no drawback to this process.
It does not make your idea any better.
Categories and Tags already have counters (assume you have no issues with them), so use 2 diferent UI approches? OK..
Anyway, I see no point in discussing this topic with you any further, as there is simple solution:
- add counters to Album/Rating/Labels to improve usability
- add checkbox to switch them off
- (optional) add setting to auto/manual update OR custom delayed update in seconds