github immich-app/immich v3.3.0

4 hours ago

v3.3.0

Note

We're collecting feedback related to people sharing in this discussion: #32196

Welcome to Immich v3.3.0!

This release includes people sharing, birthday memories, auto-stacked mobile edits, and a variety of other enhancements and bug fixes. Keep reading below for the full list of highlights.

Highlights

  • Shared people management
  • Birthday memories
  • Auto-stacked mobile edits
  • Sync OAuth claims on every login
  • Higher quality thumbnails and previews
  • Machine learning performance and accuracy improvements (opt-in)
  • New OCR models
  • Notable fix: correct storage size on MacOS

Shared people management

We are very pleased to release the next big milestone towards better sharing: people can now be shared!

As a user you can share people with another user in your cluster group:

Note

The “Manage access” modal can be opened from both the “People” (/people) and “Sharing settings” (/user-settings) pages in the web application. The modal is not available on mobile, yet.

When sharing a person with another user, the shared person:

  • Shows up in both users’ list of people (on mobile and web)
  • Shows up in the asset viewer / asset detail view on both owned and shared assets
  • Can be edited by both users (only the name & birth date fields)

Note

Person sharing is directional. This means that each user needs to share each person back for edits to automatically work in both directions.

By default, changes to the name & date of birth are reflected for both users. On the web, the “Edit person” modal has an option to change the name/date of birth for “Only me” instead of the whole group.

Also, there is a preference for this behavior in the “Sharing settings”, which can be changed to make this the default behavior when editing a person. The setting can be changed here: https://my.immich.app/user-settings?isOpen=feature+people.

The setting has two options:

  • “Everyone with shared access” — means an update will apply for everyone, covering the typical family use case where one or two users are supposed to be responsible for the entire family's people.
  • “Only me” — means the names and dates of births will remain unchanged for other users

Lastly, by allowing cross-user merging, you can now merge a face from your own assets with people shared with you from other users. This is especially helpful if you didn't want to re-run facial recognition after joining a cluster group before. Now, after setting up bi-directional sharing, users can manually link people together.

Birthday memories

In an effort of making Immich more joyful to use, we are introducing memories for people's birthdays.

If it's the birthday of a person in your library, Immich will now celebrate that with a special memory featuring previous birthdays.

Auto-stacked mobile edits

When using something other than Immich for editing images on your phone, Immich will now stack those edits on top of the original. This allows for Immich to show all edits in one place, without cluttering the timeline.

This should provide a more organized timeline, especially when you heavily rely on editing assets on your phone.

Sync OAuth claims on every login

Immich supports OAuth claims for storage quota, the user role, and the preferred username. Up until now, those were only synced on registration.

Now, they can be synced on every login, allowing you to do active user management through your IDP, updating quotas and roles as you go and as necessary, and Immich will adopt those changes.

Higher quality thumbnails and previews

Immich now uses a more accurate image resampling method, improving detail preservation and brightness, especially for high contrast details.

Before

After

Machine learning performance and accuracy improvements (opt-in)

Note

Opt-in to the new machine learning models by adding the following environment variable to the machine learning container: MACHINE_LEARNING_MODEL_REVISION=v2

After a long list of optimizations, ML is both significantly faster and uses less memory. This affects every backend, including CPU inference. However, the level of improvement varies by model and backend. Cases where certain backends (such as OpenVINO) produced wrong outputs at times should be resolved.

RKNPU, used by Rockchip boards, now supports every model in the catalog including OCR for the first time, bringing it to parity with other backends. Additionally, TensorRT RTX is now used for Ampere (30xx) and newer NVIDIA GPUs, improving performance significantly.

To fully benefit, set MACHINE_LEARNING_MODEL_REVISION=v2to allow more optimized models to be downloaded and used. Many of the improvements rely on these optimized models and will not take effect when using the old ones. The outputs of the new and old models are numerically equivalent, so switching doesn’t require re-running any tasks. This setting will be the default in a later release.

As always, keep in mind that the very first time you load a model requires more preparation work, so don’t be surprised if it takes some time at first. This preparation is cached and reused, so loading the model will be much faster after the first time.

New OCR models

The PP-OCRv6 family is now supported. These models are significantly more accurate than the previous PP-OCRv5 generation while all being multilingual. PP-OCRv6_tiny is efficient and suitable for modest hardware, PP-OCRv6_small is a notable jump in accuracy compared to PP-OCRv5_mobile, and PP-OCRv6_medium improves on PP-OCRv5_server as the highest quality and most demanding option.

Notable fix: correct storage size on MacOS

The block size used to calculate the storage capacity and usage has some nuances to it. In some situations (*cough* Docker on MacOS *cough*), we didn’t have enough information to correctly compute accurate values. With this release, the reported storage usage and capacity should now be correct.

Technical details

Recent NodeJS releases now expose the frsize property, which is sometimes different from bsize (“block size”). In those cases the calculate storage sizes could often be off by a factor of4096 (or more). In fact, #4318 has been our fourth oldest open issue (including the renovate dashboard), opened just over three years ago. Now, with accurate block sizes our storage calculation should be correct, even in Docker on MacOS.

We are very happy to finally see this issue resolved, even though it only meant a dependency bump and a tiny code change for us.

As always, please consider supporting the project.

🎉 Cheers! 🎉


And as always, bugs are fixed, and many other improvements also come with this release.

What's Changed

🚀 Features

🌟 Enhancements

🐛 Bug fixes

📚 Documentation

🌐 Translations

New Contributors

Full Changelog: v3.2.4...v3.3.0

Don't miss a new immich release

NewReleases is sending notifications on new releases.