Does the randomisation process weight more recent photos more heavily?

[semiligneous]

Everything works fine, I have kiosk set up to display photos of particular people (the kids). The photos that are shown seem to all be from the last few months, occasionally older, but rarely from before May 2024 it seems . Of course, maybe I missed one but I reduced the refresh to 5 seconds and watched a while!

If I change the person to someone else, who I only have older photos for, I see the older photos. So I have 2 hypotheses:

1. The randomisation deliberately weights more recent photos. If so, that is sensible, but I'd like to control it somewhat as it seems too weighed to recent ones.

2. the search process to get a random photo somehow only returns a subset of the possible photos, and the order is accidentally done by date.

I do have a lot of photos for these faces, 7,000 for one and 17,000 for the other in immich stretching back multiple years.

Any thoughts?

[damongolding]

I don't believe it does. I use the Immich getRandom endpoint so if it's weighted. It will be on Immichs end.

[semiligneous]

the getRandom API endpoint doesn't seem to have any way to pass a Person ID or Album ID according to the documentation here:

https://immich.app/docs/api/get-random

How are you getting a random asset with specific person ID?

[damongolding]

Sorry I misunderstood your answer. It seems that the person api limits responses to 1000 so I will have to look into how to get them all. Thanks!

[damongolding]

Looks like that API endpoint is deprecated. I have found the way Immich uses but it's going to take some work to get it up and running

[semiligneous]

It seems ImmichFrame suffers from a similar issue - I'm only seeing recent photos when providing a PersonID that has many thousands of assets there too.

It seems the most ideal solution would be for Immich to add features to the getRandom endpoint to allow filter criteria/on (such as album ID/s and personID/s) and then Immich can run the randomization directly from the database.

Any solution which requires the client to get a full/large list of IDs and then randomize those will hit some type of an issue when the numbers get large.

Not to say there's not a work around in the meantime, but perhaps effort is best spent elsewhere if there's a simpler solution available by Immich core team?

[damongolding]

I have already reached out to the creator of ImmichFrame to ask how he deals with this issue but I have already found a solution. I just need to implement it.

My intended implementation:

• You can get a list/buckets of a persons assets broken down into months (a timestamp is given). I would probably cache this response.
• Then we would grab one of these months at random, then retrieve the bucket of assets.
• Randomise those assets and retrieve the first asset that matches the users criteria (this logic already exists in Kiosk)
• Finally grab the images raw data and serve it up.

The benefit of this solution is that you get access to all the assets. Not just the limited 1000 that the person api enforces.

[semiligneous]

That does make sense, although it would give months with less photos a higher frequency/likligood than they deserve. Eg if January 2024 has only 1 photo, but every other month from 2023 to 2024 (eg 20 months) had 1000 in each, then there’s a 1 in 20 chance you choose January 2024, and when you choose that month you have to serve up that same image. Despite the fact that there’s actually 20,001 images you would see the same image once every 20. Of course, that’s an extreme example but something approaching that could occur. How do you handle multiple personIDs? a similar thing may happen there too, as you’d be bucketing based on uneven numbers but giving the buckets even weight. Is this a big deal? Not really, it’ll probably be ok! But the better way is for Immich Core code to offer a true randomized asset with particular inclusion criteria (person ID/s or album IDs or dates etc)

…

----- Original message ----- From: "Damon - notifications at github.com" ***@***.***> To: "damongolding/immich-kiosk - immich-kiosk at noreply.github.com" ***@***.***> Cc: semiligneous ***@***.***>, "Author - author at noreply.github.com" ***@***.*** ***@***.***>> Subject: Re: [damongolding/immich-kiosk] Does the randomisation process weight more recent photos more heavily? (Discussion #76) Date: Thursday, 12 September 2024 19:38 I have already reached out to the creator of ImmichFrame to ask how he deals with this issue but I have already found a solution. I just need to implement it. My intended implementation: • You can get a list/buckets of a persons assets broken down into months (a timestamp is given). I would probably cache this response. • Then we would grab one of these months at random, then retrieve the bucket of assets. • Randomise those assets and retrieve the first asset that matches the users criteria (this logic already exists in Kiosk) • Finally grab the images raw data and serve it up. — Reply to this email directly, view it on GitHub <#76 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOYQN4JG3J63A3W3SIPVROTZWFOIXAVCNFSM6AAAAABN6U5OMCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTANRSGQYTONY>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[damongolding]

Hmm yes I see how that could happen.

A possible fix could be to create a pool of dates with the same amount of timestamps as images?

Example data from Immich 👇

[
  {"TIMASTAMP_1", "images", 1}, 
  {"TIMASTAMP_2", "images", 5},
]

Then create the pool akin to something like this which the random timestamp is taken from?

[
 "TIMASTAMP_1",
 "TIMASTAMP_2",
 "TIMASTAMP_2",
 "TIMASTAMP_2",
 "TIMASTAMP_2",
 "TIMASTAMP_2"
]

[jschwalbe]

I'm not sure if this is a real problem, but what if a month has > 1000 assets? If that's the case, months probably wouldn't be the hoped-for solution.

Per this this immich discussion it appears that the recommended move to go > 1000 entries is to use the search-metadata API call, as it can be paginated. (Why isn't everything paginated is a good question. :))

Not sure if this helps, but thought I'd throw it out there.

[damongolding]

I've had very little success with the metadata api endpoint but it definitely is worth exploring.

[jschwalbe]

FWIW I did some playing around with it and was able to generate results using search-metadata with input of personIds (but haven't figured out a way to pull an album, which may not even be a problem).

curl -L '$IP:$PORT/api/search/metadata' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'x-api-key: $API_KEY' -d '{
  "personIds" : [ "$PERSON_ID1",  "$PERSON_ID2" ], "page": $PAGE, "size": 1000
}'

Of note: personIds is ANDed, so if $PERSON_ID1 and $PERSON_ID2 are not both identified in the same picture, zero items are returned. You'd need two separate API calls to get all pictures with $PERSON_ID1 and all pictures with $PERSON_ID2. I assume that would be the plan unless a config option was changed.

The very end of the output contains "nextpage" which is either a number or null. Also, $PAGE starts at 1, not 0.

Randomizing is up to you from here :)

[damongolding]

Thanks for this. It’s good to know that personsID is AND, as I thought it was OR. My main issue with this route (which will be super easy in Go) is do I cache the results, as that could be a lot of data. I guess I could store a number of filtered results and when those run out repeat the process 🤔

…

On 12 Sep 2024 at 8:56 PM +0100, jschwalbe ***@***.***>, wrote: FWIW I did some playing around with it and was able to generate results using search-metadata with input of personIds (but haven't figured out a way to pull an album, which may not even be a problem). curl -L '$IP:$PORT/api/search/metadata' -H 'Content-Type: application/json' -H 'Accept: application/json' -H 'x-api-key: $API_KEY' -d '{ "personIds" : [ "$PERSON_ID1", "$PERSON_ID2" ], "page": $PAGE, "size": 1000 }' Of note: personIds is ANDed, so if $PERSON_ID1 and $PERSON_ID2 are not both identified in the same picture, zero items are returned. You'd need two separate API calls to get all pictures with $PERSON_ID1 and all pictures with $PERSON_ID2. I assume that would be the plan unless a config option was changed. The very end of the output contains "nextpage" which is either a number or null. Also, $PAGE starts at 1, not 0. Randomizing is up to you from here :) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: ***@***.***>

[semiligneous]

@damongolding I see in your latest release that you now handle the "next image" logic in the background, which opens up more processing time, so I guess the workaround options (handling randomization and large volumes of meta data) are more acceptable.

[damongolding]

Somewhat yes. It was never really too much of an issue in terms of Kiosk being able to handle the job. I'm just trying to be respectful (as much as I am able) to the Immich API and the users server resources.

[semiligneous]

I think that’s my fundamental point: at some point, with larger enough albums or people or whatever, you end up needing to potentially cache a lot of data just to serve up one random photo! It seems inefficient overall, for what really should be a lightweight client. From my point of view, working directly with Alex and the core Immich team to see if you can update the the getRandom endpoint to be more customizable would benefit ImmichFrame, Immich-Kiosk and other future projects. And would be a far more efficient and elegant solution overall!

[jschwalbe]

I'm preparing a pull request for immich that works on the searchMetadata function here. The new code, if approved and merged, would allow for data to be sorted randomly. (Currently it appears to be sorted by fileCreatedAt date.) (I have to figure out how to make a pull request.. haha!)

My question, @damongolding, and maybe I could make this a new discussion, is how do you handle the case where someone has a face and an album defined? Do you alternate between each source, or something different? Seems like there is never going to be a way to ask immich for a random asset from 3 different buckets (even with my changes).

[damongolding]

If a user had a person and an album ID set, they are all put into a slice/array and one is picked at random. Depending on the “type” Kiosk then goes about fetching the asset. I did try going down the path of trying to satisfy both ids at the start of Kiosk i.e. find a album image with person in but that wasn’t a good idea lol

…

On 14 Sep 2024 at 7:41 PM +0100, jschwalbe ***@***.***>, wrote: I'm preparing a pull request for immich that works on the searchMetadata function here. The new code, if approved and merged, would allow for data to be sorted randomly. (Currently it appears to be sorted by fileCreatedAt date.) My question, @damongolding, and maybe I could make this a new discussion, is how do you handle the case where someone has a face and an album defined? Do you alternate between each source, or something different? Seems like there is never going to be a way to ask immich for a random asset from 3 different buckets (even with my changes). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jschwalbe]

Haha yeah I could see that not working super well.
So just to play devils advocate.. if there is an album with 1 photo and one with 99, the one photo would get shown on average 50% or do you try to weight it based one # of assets? Getting deep in the weeds here lol

[damongolding]

Haha yeah I could see that not working super well. So just to play devils advocate.. if there is an album with 1 photo and one with 99, the one photo would get shown on average 50% or do you try to weight it based one # of assets? Getting deep in the weeds here lol

In this situation it would work as you've described yes. I could use getAllAlbums which sends back the asset number that each album contains, then use that to do some balancing 🤔

You do like to keep me on my toes @jschwalbe

[damongolding]

Out of curiosity does your pull request make alterations to the `order` param or does it add a new one?

…

On 14 Sep 2024 at 7:41 PM +0100, jschwalbe ***@***.***>, wrote: I'm preparing a pull request for immich that works on the searchMetadata function here. The new code, if approved and merged, would allow for data to be sorted randomly. (Currently it appears to be sorted by fileCreatedAt date.) My question, @damongolding, and maybe I could make this a new discussion, is how do you handle the case where someone has a face and an album defined? Do you alternate between each source, or something different? Seems like there is never going to be a way to ask immich for a random asset from 3 different buckets (even with my changes). — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jschwalbe]

Yeah the code I pasted was old, the gist had it right, I think?

[damongolding]

Yeah you’re right. Where it says if (options.random) is wrong.

I changed it at one point but it worked its way back in without me noticing.

Sneak code. The worst kind of code! I did think about creating a pull request but jumping into large project like Immich require time to understand how things work etc. Also, I avoid JS where possible.

[damongolding]

Yeah the code I pasted was old, the gist had it right, I think?

Is there more alterations to your pull request? I assume "asset.fileCreatedAt" turns into a SQL query. So I assume you will need to make a new one for "RANDOM"?

[jschwalbe]

The stuff in the gist is all I've thought to change - asset.fileCreatedAt is only for telling it how to sort, AFAIK, the rest of the code that builds the request is untouched. Trying to figure out how to test it locally before trying a pull req.

[damongolding]

The stuff in the gist is all I've thought to change - asset.fileCreatedAt is only for telling it how to sort, AFAIK, the rest of the code that builds the request is untouched. Trying to figure out how to test it locally before trying a pull req.

Ahh so the @GenerateSql decorator is what builds the SQL query, can't believe I missed that.

[damongolding]

@semiligneous @jschwalbe do you fancy testing the beta of Kiosk 0.10.0 for me?

I have implemented some asset weighting. So if you have 2 album IDs in which one has 1 image and the other has 1000. In 0.10.0 you shouldn't see the album with 1 image 50%(ish) of the time anymore.

The beta docker image is damongolding/immich-kiosk-development:0.10.0

[semiligneous]

I'll give it a go shortly @damongolding and will report back.

Just so I know what to expect, this won't solve my initial issue of seeing photos that are recent though right (when the person ID/s has many thousand images)?

Will this change also work for 2 person IDs when one of the people have eg 1 image and the other has many?

[damongolding]

Just so I know what to expect, this won't solve my initial issue of seeing photos that are recent though right (when the person ID/s has many thousand images)?

@semiligneous Kiosk is still using the 1000 limited person api at the moment, so you will still see recent images (I am looking into a Immich side fix for this). And yes it will work for both people and albums yes.

🙏

[semiligneous]

so the new 0.10.0 dev branch definitely weights photos more appropriately now.

my test was adding 2 people (person IDs), one with 76 assets, the other with 7,000+ assets, and setting to refresh=5 and watching it a while. Very scientific...

On the main release, the person with only 76 assets is shown very often, the same image also comes up regularly. It seemed slightly skewed to the person with more images, but only just. If I watched it long enough it might be 50-50.

On the dev release, the person with 76 assets rarely shows up - eventually they show, then it's back to the other person for the majority of the time. In theory should only see the less common person 76:7000 ratio (about 1 in 100), but due to the 1,000 limit API restriction, I'm guessing it's going to end up nearer 76:1000 (1 in every 13). And that's approx what I saw.

=> This is consistent with what you were trying to achieve.

[damongolding]

Thanks @semiligneous! I feel like I should be paying you for such scientific testing

[jschwalbe]

Sorry I didn't get a chance to test it, but it sounds like it passed!

BTW: here's my PR for immich; currently in litigation.

[damongolding]

I've subscribed and wait with baited breath

[semiligneous]

I see that some comments have been made on the Immich pull request but it's not clear what happens next?! Are they suggesting to make changes to address the concerns?

[jschwalbe]

I made the changes they requested, and was prepared to push them, but then I was chatting with the immich devs and they wanted to do something different still! So I may try to do the next different thing, or let them do it. But it's on their radar at least :)

[damongolding]

If they want to add filters to the randomApi endpoint then it’s a huge win.

…

On 19 Sep 2024 at 2:18 PM +0100, jschwalbe ***@***.***>, wrote: I made the changes they requested, and was prepared to push them, but then I was chatting with the immich devs and they wanted to do something different still! So I may try to do the next different thing, or let them do it. But it's on their radar at least :) — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[jschwalbe]

Yeah, that would be cool. They don't like the RANDOM() call bc it's resource intense with large library. I get that.

[semiligneous]

Yeah that would be perfect solution right? It would allow Kiosk to simply pass the filters (album/person ID etc) straight through and get a random image back. Am I understanding correctly?

[damongolding]

Yeah that would be perfect solution right? It would allow Kiosk to simply pass the filters (album/person ID etc) straight through and get a random image back. Am I understanding correctly?

That's right. Though I would be tempted to still use my current logic for albums and people because of the weighting but this would simplify the selection process a lot.