Amped up bucket filtering and asset weighting

[nicodemusjls]

I have searched the existing feature requests to make sure this is not a duplicate request.

• Yes

The feature

I think I have a solution that wouldn't be very difficult to implement and would superpower our control over bucket filtering and asset weighting in one go.

I and others have wanted more control over the filtering and weighting of assets. In particular, the most common I've seen is the need for more recently added photos to be shown more frequently than old assets. One solution to that is to create multiple buckets via the Date Range and turning Weighted Assets off. By controlling bucket date ranges and allowing random bucket usage, we've indirectly weighted the date ranges. However, since we can't then additionally filter to an album or people, etc., many of us are stuck because we still need those. If we start with an Album based bucket and filter to dates, we lose the indirect weighting effect.

That is just one example of many nuanced issues that would be addressed by the following two recommendations.

Ability to filter buckets independently and to control quantity of assets added to individual buckets. I know that seems like a lot of work to implement, but I think I have a solution that would actually be quite easy.

The following would allow a simple way of implementing filtering based on people/album/etc AND be able to do it on a per bucket bases allowing granular control without having to build new url paramaters. It would give us AND/OR control over bucket creation.

The idea is to use the tilde as a flag for filters within parameter values. When setting any value to Album, People, Date Range, etc. you would simply suffix with a tilde followed by any other of these same existing keys to use it as a filter. The top level value would simply be parsed/split looking for any tildes and anything it finds would be used as a filter on that particular bucket.

Example: Two album buckets, each filtered to different date ranges
Use case: self-explanatory
Usage: http://{URL}?album={album_id_A}~date=2025-01-01_to_today&album={album_id_B}~date=2000-01-01_to_today&asset_weighting=true

Example: Three date buckets, each filtered to a specific album
Use case: Allows the source to be one Album, but allows recently added photos to be weighted more heavily with asset weighting off because date ranges will naturally affect bucket sizes)
Usage: http://{URL}?date=today~album={album_id}&date=last-7-days~album={album_id}&date=last-365-days~album={album_id}&asset_weighting=false
The above could also be created by making three buckets from the same album source and each filtered to a different date range. Whatever is intuitive to the user.

Example: A person bucket filtered to include a second person, and an album bucket unfiltered
Use case: A user wants to only see photos of their friend and themselves together, and photos from a shared album.
Usage: http://{URL}?person={person_id_A}~person={person_id_B}&album={album_id}

While the base usage of the parameters function like OR statements, the usage of the tilde functions like an AND statement within it, creating a natural structure for bucket creation: ( x AND y ) OR ( s AND t AND u AND v) OR ( d AND e AND f )

I believe this structure would allow for nearly all bucket customization. It would also allow using the existing bucket size weighting feature (on or off) to function more broadly and indirectly add weight to dates/persons/etc because we can fully control bucket content. If implemented in the code, it would also mean that any new top level bucket parameters inherently can also be used as filters.

The second concept would be a 'quantity' parameter to control how many assets where pulled into individual buckets, it would make the existing weighting feature universally usable to effectively control the weight of persons/albums/dates etc. This way individual weighting mechanism wouldn't have to be created for each bucket source type. We just control how many assets go into the bucket in the first place.

I believe that by adding bucket level filtering as described above would meet all current and future bucket customization needs and even address some asset weighting desires by the community. Then, by adding bucket size control with a Quantity parameter, we would have full control over our bucket contents. Even the most nuanced and complex use cases could be inherently achieved with AND/OR control of source and Quantity control of bucket size.

[nicodemusjls]

Well. I only dabble in programming, and I don't have any experience with Go. But, now that I started looking at the code, I'm wondering if this might be more difficult than I expected. I guess I assumed a specific approach to the programming structure, and I'm not sure if it's the same as you have currently. I guess I expected a main function to 'build' a base query to be used later with Immich API Search Random. Then, if the kiosk received a config parameter for, let's say, Album, it would call a function that would just add the needed parameters to that base query as directed by its value. As such, next, using a Person parameter as a filter would be as easy as calling a People function that would then add to that same query it's needed values. Those same Album, People, etc. functions could be used at the top level or filter level just the same because all they are doing is adding parameters to the base query and it wouldn't really matter if one occurred first or second. Then, when finished building all needed API queries, the calls would be made to the Immich API and assets fetched. Lastly, the results list would just be truncated by any Quantity value we provided.

But, maybe the current code is structured differently. It looks like the Immich API call is being made and processed within each of the various functions for Album, Person, etc.. I'll continue to look. Maybe there is still a simple way of doing this.

[damongolding]

Out of curiosity who are the other that want this feature? Have I missed a discussion or conversation?

Correct me if I’m mistaken, but I believe your view on kiosk asset weighting is not quite right. Kiosk asset weighting rebalances the chances that assets are shown; it reduces the likelihood that buckets containing only a few assets are repeatedly displayed, ensuring a fairer distribution across buckets.

[nicodemusjls]

Sorry for the confusion, the "others" are from my personal circles, not from these github discussions. I think I only saw one similar feature request in this forum.

I was under the impression that 'unweighted' assets get over presented when a small bucket is next to a larger bucket because the kiosk randomly chooses from one bucket or the other. For example, two buckets would be 50-50 chance from each bucket. If the small bucket has only a few assets and the large bucket many, the smaller bucket's assets get shown disproportionately often. I thought the Weighted Assets function fixes that by giving a weight value in some way that evens the odds. But, there is a good chance I completely misunderstood how it works.

I'm no where close enough to knowing how to do what you do, but just enough to think I understand how things are working even when I don't. :)

[damongolding]

That's pretty much how asset weighting in Kiosk works. I think I misunderstood your example turning it off to make you're own weighting using multiple date buckets. Which, I must say is pretty smart! I never thought of that case usage before.

[damongolding]

As for code structure. For Kiosk to work as it does it has to use multiple different api endpoints, which can vary quite significantly, e.g you can't get random album assets from the random search Immich endpoint. Also, with some buckets/features Kiosk does the majority of data processing/randomisation rather than the random Immich endpoint.

[nicodemusjls]

Thanks for the explanation. I didn't realize that different end-points were being used to fetch assets.

Well, obviously, I'm still passionately hopeful for the customizations mentioned, but it's obviously a bigger project than I thought it might be.

Your tool has provided a great experience for my family. We each have a digital frame in our own homes, and we share photos of our lives into one shared album that displays in each home. It's so amazing and promotes so much conversation and connection when we randomly see photos from each other's lives right there on the fireplace or coffee table. Obviously, social media platforms do this also, but we don't have all the clutter of posts from all the things we follow. Even the fact that photos show up without text and comments stimulates curiosities and more personal conversations. It's great. Thanks for this tool.

As you can imagine from my family's use case, I wish there was a way for newly added photos to the album to show up much more frequently, not based on photo taken date, but the 'added to album' date. But, that is a big dream. I haven't found anything in the Immich API yet that would tell me the date a photo was added to the album.

Anyway, if you haven't caught on, I like to write. Sorry for the long essays. ;)

And thank you for what this tool already does. It's amazing and beautiful.