album feature request : number of images

[Gwenael Q.]

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

[user0]

+1

it would be nice to have counters for:
- rating
- color labes

[m.Th.]

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.

[user0]

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.

this is ridiculously unusable approach

Trickier to do for Albums because for many albums and many photos it can be slow.

it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..

[m.Th.]

it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..

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?

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.

this is ridiculously unusable approach

Harsh words. Care to explain?

[user0]

it must be magic how other apps (Capture One, Lightroom, etc) have implemented this technique
if only you know about parralel tasks, workers..

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?

rly? hope you're a better db than UX "programmer".
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

now tell me what number of records will cause execution time of these 3 queries to be slow, eg >few seconds

Bad Lr design decisions hinder the size of catalogs which is also a common problem for Lr.

I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.

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.

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.
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.

this is ridiculously unusable approach

Harsh words. Care to explain?

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.

[m.Th.]

rly? hope you're a better db than UX "programmer".

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”.

now tell me what number of records will cause execution time of these 3 queries to be slow, eg >few seconds

The first one is problematic because in albumslink table is a m:n relationship which in some cases will explode the table's cardinality.

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.

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.

Sorry, but your solution is flawed because many users - including myself - have Filter Catalog open & visible at startup.

I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.

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.

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.

Explain why clicking on every Rating/Color/Album to check its counter is bad idea?

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”.

against main purpose of such counters

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))

[user0]

rly? hope you're a better db than UX "programmer".

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”.

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.

now tell me what number of records will cause execution time of these 3 queries to be slow, eg >few seconds

The first one is problematic because in albumslink table is a m:n relationship which in some cases will explode the table's cardinality.

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

Again, without your bla-bla, how many records?

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.

Sorry, but your solution is flawed because many users - including myself - have Filter Catalog open & visible at startup.

you didn't quote the whole paragraph on purpose, did you?

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.

I have no complains about lr filtering speed of my ~100k files. I must be doing something wrong.

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.

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).

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.
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.

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.

Thats the issue, a) there shall be option to switch off auto-import and b) Catalog shall be browsable.

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.

Manual import adds no drawback to this process.

Explain why clicking on every Rating/Color/Album to check its counter is bad idea?

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”.

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