[Feature] Allow "boosting" of images by criteria (date, size, etc)

[steveredden]

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

• Yes

The feature

Feature Request: Asset Weighting / Boost Rules for Slideshow Frequency

Summary

Add a configurable "boost" system that lets users assign relative weights to assets based on metadata criteria, so certain photos appear more frequently in the slideshow without fully excluding others.

Motivation / Use Case

I use Immich Kiosk as a shared photo display for remote family members, cycling through photos of two people using the person config option. The slideshow pulls photos via Immich's random asset API, which gives every qualifying photo equal probability of appearing.

In practice, this creates two problems:

1. Recency — family members are most interested in recent photos, but older photos dominate by sheer volume. A photo from five years ago has the same likelihood of appearing as one from last week.
2. Quality variance — some photos come from a daycare that uses a low-resolution camera. These are less compelling to display but I don't want to exclude them entirely — just show them less often.

There's currently no mechanism to influence how often a photo appears short of excluding it entirely (e.g. via albums, date ranges, or rating filters).

Proposed Solution

Introduce a weights (or boost) configuration block that allows users to define rules with multipliers. When Kiosk selects the next asset, it applies these weights to bias selection probability — assets matching higher-weight rules appear more frequently.

Example config:

weights:
  - match:
      date_range: "last_90_days"
    multiplier: 3.0
  - match:
      min_megapixels: 10
    multiplier: 2.0
  - match:
      make: "Apple"       # EXIF camera make
    multiplier: 1.5
  - match:
      min_megapixels: 0
      max_megapixels: 4
    multiplier: 0.25      # deprioritize low-res sources

Weights would stack multiplicatively (or additively — whichever is simpler to implement). An asset matching no rules gets a neutral weight of 1.0.

Potential Match Criteria

Listed roughly by implementation complexity (easiest first, since all of this data is already in the Immich asset response):

• date_range — relative ranges like last_30_days, last_90_days, last_year, or absolute year ranges
• min_megapixels / max_megapixels — computed from exifInfo.exifImageWidth × exifInfo.exifImageHeight
• make / model — exifInfo.make, exifInfo.model
• min_rating — already supported as a filter; could also be used as a weight
• type — IMAGE vs VIDEO

Implementation Notes

Since Kiosk already fetches a pool of random assets from Immich before displaying them, weighted selection could be applied client-side within Kiosk at the point of choosing which asset to display next from the pool — no Immich API changes needed. A weighted random selection (e.g. using a standard alias method or simple linear scan) over the fetched pool would be sufficient.

This avoids any additional API calls and keeps the feature entirely within Kiosk's control.

Alternatives Considered

• Multiple albums with different refresh intervals — not supported; Kiosk cycles sources uniformly.
• Rating filter — can exclude low-rated photos entirely, but doesn't allow soft deprioritization.
• Date range filter — can restrict to recent photos only, but then older family memories never appear, which isn't the goal.

A weighting system is the natural middle ground: everything is still eligible, just not equally likely.

Additional Context

Current setup: two person IDs configured, default random asset behavior, no album filtering. The feature would be most useful as a config.yaml / environment variable option, with potential URL param support for per-device overrides (consistent with how other Kiosk settings work).