PhotoPrism או Immich: מהו שרת התמונות המתאים לכם?

PhotoPrism מול Immich: התשובה הקצרה

הבחירה בין PhotoPrism לבין Immich היא בחירה בין שתי משימות שונות, ולא בין שתי גרסאות של אותו מוצר. Immich מחליף את Google Photos: אפליקציה לטלפון מגבה את גלריית התמונות באופן אוטומטי, וציר הזמן שמתקבל ייראה מוכר לכל מי שעוזב גלריית טלפון סטנדרטית. PhotoPrism מארגן ספריית תמונות שכבר קיימת אצלכם: הוא מבצע אינדוקס לתיקיות קבצים בדיסק, קורא את ה-metadata שלהם, מציב אותם על מפה, ומשאיר את הקבצים בדיוק במקום שבו היו.

בחרו ב-Immich אם הבעיה היא "הטלפון שלי מלא ואני רוצה לצאת מ-Google Photos". בחרו ב-PhotoPrism אם הבעיה היא "יש לי 400 GB של תמונות על כונן ואני לא מצליח למצוא בהן כלום". שניהם קוד פתוח, שניהם רצים כ-Docker containers על VPS רגיל, ושניהם מבצעים אינדוקס וחיפוש בספרייה שלכם מבלי לשלוח דבר לצד שלישי.

הפילוסופיה השונה, ומדוע היא מכריעה הכל

Immich מחזיק בבעלות על הקבצים. אתם מצביעים על מיקום העלאה, אפליקציית הטלפון או מעלה הקבצים בדפדפן שולחים את המקורות פנימה, ו-Immich מאחסן אותם תחת נתיב משלו עם שמות משלו. מסד הנתונים מחזיק את האמת לגבי אלבומים, פנים וחיפוש. תכנון זה הוא מה שהופך את חוויית השימוש בטלפון לטובה, כיוון שהשרת תמיד מכיר את המצב המלא של כל נכס.

PhotoPrism קורא את הקבצים. אתם מבצעים mount לתיקיית originals שאתם כבר שולטים בה, ו-PhotoPrism בונה עליה אינדקס. עץ הספריות שלכם נשאר שלכם. אם תסירו את PhotoPrism מחר, התמונות יישארו שם באותן תיקיות עם אותם שמות, ו-PhotoPrism יהיה זה שכתב קובצי sidecar בפורמט YAML לידן, המתארים את מה שלמד.

ההבדל היחיד הזה מסביר את רוב השאר. ל-Immich יש תמיכה חזקה במובייל כיוון שהוא שולט בתהליך הקליטה. ל-PhotoPrism יש יכולות אוצרות ספרייה חזקות כיוון שהוא לעולם לא נלחם במבנה הקיים שלכם. Immich הוא התשובה הטובה יותר עבור משפחה שהתמונות שלה נמצאות בטלפונים. PhotoPrism הוא התשובה הטובה יותר עבור ארכיון שנמצא על דיסק.

דרישות חומרה: Immich צורך יותר

רצפות הזיכרון המתועדות רחוקות זו מזו, ובשרת VPS קטן זהו לרוב הגורם המכריע.

[
  {
    "label": "Immich",
    "min_ram_gb": 6,
    "recommended_ram_gb": 8
  },
  {
    "label": "PhotoPrism",
    "min_ram_gb": 3,
    "recommended_ram_gb": 4
  }
]

Immich מתעד 6 GB של RAM כמינימום ו-8 GB כמומלץ, עם הערה שמכונה עם 4 GB יכולה להריץ אותו רק אם למידת מכונה (machine learning) כבויה. PhotoPrism מתעד 3 GB של זיכרון פיזי ושתי ליבות CPU, ומציין שכמות ה-RAM צריכה להתאים למספר הליבות.

הפער אמיתי, והוא נובע ממכולת למידת המכונה. Immich מריץ את המודלים שלו בשירות immich-machine-learning נפרד הטוען מודלי CLIP (קיצור של contrastive language image pretraining) ומודלי זיהוי פנים לתוך הזיכרון. במכונה עם 2 GB ה-kernel הורג את המכולה, ואתם תראו אותה יוצאת עם קוד 137, שזו הדרך שבה Docker מציג עצירה עקב חוסר בזיכרון (OOM kill). המודלים של TensorFlow ב-PhotoPrism קטנים יותר והוא מבצע דגרדציה במקום לקרוס: במכונות עם 1 GB או פחות הוא משבית המרת RAW ו-TensorFlow במקום לקרוס.

שני הפרויקטים דורשים swap. התיעוד של PhotoPrism מפורש לגבי הצורך ב-swap של לפחות 4 GB בשרת. הוסיפו אותו לפני שתתקינו את אחד מהם.

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
free -h

free -h אמור כעת להדפיס שורת Swap: המציגה 4.0Gi. אם הוא מדפיס 0B, אזי swapon נכשל, בדרך כלל משום שמערכת הקבצים אינה תומכת ב-fallocate, ו-sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 הוא ברירת המחדל החלופית. תקרות זיכרון למכולות חשובות גם כאן, ו-הגדרת מגבלות זיכרון ב-Docker Compose היא הדרך למנוע משירות רעב אחד להפיל את כל השרת.

דרישה נוספת מפתיעה משתמשים. מסד הנתונים Postgres של Immich חייב לשבת על מערכת קבצים Unix רגילה עם בעלות והרשאות תקינות, על אחסון מקומי, ולעולם לא על כונן רשת. PhotoPrism מציין את אותו הדבר לגבי קובצי מסד הנתונים שלו. לא בטוח להריץ אף אחת מהאפליקציות הללו כאשר מסד הנתונים שלהן נמצא על object store ממופה.

כיצד להתקין כל אחד מהם

שתי ההתקנות מבוססות על קובץ compose של הספק ופקודה אחת. תחילה יש להגדיר את Docker Engine ואת התוסף Compose, כפי שמוסבר ב-מדריך שלנו ל-Docker Compose ב-VPS.

Immich מפרסמת את קובץ ה-compose שלה וקובץ סביבה לדוגמה עם כל גרסה שיוצאת.

sudo mkdir -p /opt/immich && cd /opt/immich
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env

יש לערוך את .env לפני שמתחילים בכל פעולה. UPLOAD_LOCATION הוא המיקום שבו יישמרו הקבצים המקוריים שלכם, ואת DB_PASSWORD יש לשנות מהערך המוגדר כברירת מחדל תוך שימוש בתווים A-Za-z0-9 בלבד, כיוון שתווים מיוחדים משבשים את מחרוזת החיבור. לאחר מכן, ניתן להפעיל את השירות.

docker compose up -d
docker compose ps

ממשק האינטרנט מאזין בפורט 2283. החשבון הראשון שנרשם דרך דף זה הופך למנהל המערכת, לכן יש לגשת אליו ולהירשם מיד במקום להשאיר מופע פתוח וחשוף לאינטרנט.

PhotoPrism מספקת קובץ compose אחד שכבר כולל את MariaDB.

sudo mkdir -p /opt/photoprism && cd /opt/photoprism
wget https://dl.photoprism.app/docker/compose.yaml

יש לפתוח את compose.yaml ולשנות את PHOTOPRISM_ADMIN_PASSWORD לפני ההפעלה הראשונה. התיעוד מבהיר זאת ללא כחל וסרק: היישום עולה עם כל סיסמה ראשונית שמופיעה בקובץ זה, האורך המינימלי הוא 8 תווים, ואסור להשתמש בערך ברירת המחדל בשרת ציבורי. במקביל, יש להגדיר את ה-volume של originals לתיקייה המכילה את התמונות שלכם.

docker compose up -d
docker compose logs -f photoprism

PhotoPrism מאזין בפורט 2342 עם המשתמש admin. אין לחשוף אף אחד מהיישומים ישירות. יש להציב reverse proxy עם TLS (אבטחת שכבת תעבורה) בחזית, באותו מבנה ששימש עבור Nextcloud בהתקנה עצמית עם Docker, TLS וגיבויים.

לאיזה פרויקט יש אפליקציית טלפון טובה יותר

כאן הפער בין שני הפרויקטים הוא הגדול ביותר, וזו הסיבה שרוב המשתמשים בוחרים בסופו של דבר ב-Immich.

Immich מפיצה אפליקציות רשמיות עבור Android ו-iOS. הן מבצעות גיבוי רקע של גלריית התמונות, מה שאומר שתמונות חדשות עוזבות את הטלפון מבלי שיהיה צורך לפתוח דבר. האפליקציה דורשת נקודת קצה ב-HTTPS, לכן ה-reverse proxy אינו אופציונלי אם בכוונתכם להשתמש בה מחוץ לבית.

ל-PhotoPrism אין אפליקציה מקורית רשמית. היא מפיצה Progressive Web App, שאותה מוסיפים למסך הבית מתוך הדפדפן, והיא מתעדת את WebDAV (ראשי תיבות של Web Distributed Authoring and Versioning) כדרך לסנכרון מהטלפון. הפרויקט ממליץ על אפליקציה צד-שלישי בשם PhotoSync למטרה זו, המופנית לספריית /import/ או /originals/ באמצעות WebDAV. זה עובד, אך מדובר באפליקציית צד-שלישי בתשלום שמבצעת עבודה ש-Immich עושה בתוך הלקוח שלה.

אם הדרישה היא גיבוי טלפון אוטומטי עבור כמה בני משפחה, ההחלטה ברורה: Immich.

מה למידת מכונה באמת נותנת לכם

Immich מבצע חיפוש סמנטי בספרייה שלכם באמצעות CLIP, כך ששאילתה כמו "אופניים אדומים בשלג" תמצא תמונות שאף אחד לא תייג מעולם. הוא מבצע גם זיהוי וקיבוץ פנים, וזיהוי כפילויות. אינדוקס של ייבוא גדול על גבי ה-CPU נמשך שעות ברקע; זהו מצב תקין ואין צורך ב-GPU (יחידת עיבוד גרפי).

PhotoPrism מסווג תמונות באמצעות TensorFlow לתוויות, מזהה פנים ומקבץ אותן לאנשים, וקורא מטא-דאטה של מיקום כדי לבנות מפת מקומות. המפה היא התכונה שבגללה אנשים נשארים: ספרייה שמקוטלגת לפי המקום שבו התרחשו האירועים היא דרך שונה באמת לעיין בעשרים שנה של תמונות. זיהוי פנים כלול בגרסת ה-Community החינמית. מנויי ה-Essentials וה-Plus בתשלום מוסיפים תוספות כגון שכבות מפה עשירות יותר, תפקידי משתמש נוספים וממשק ניהול משתמשים, החל מכמה אירו לכל חודש נכון ליולי 2026.

Immich הוא חינמי לחלוטין ללא שכבת תשלום. הליבה של PhotoPrism היא חינמית, עם תוספות אופציונליות בתשלום.

גיבויים קובעים אם המידע יישמר

שרת תמונות ללא גיבוי נמצא במרחק כשל דיסק אחד מאובדן כל מה שיש למשפחה. שני היישומים דורשים שני גיבויים: מסד הנתונים והקבצים.

עבור Immich, בצעו dump למסד הנתונים מתוך ה-container של Postgres והעתיקו את מיקום ה-upload.

docker exec -t immich_postgres pg_dump --clean --if-exists --dbname=immich --username=postgres | gzip > /backup/immich-db.sql.gz

לאחר מכן גבו את UPLOAD_LOCATION. התיקיות המכילות מידע שאין לו תחליף הן upload, library ו-profile. את התיקיות thumbs ו-encoded-video ניתן לשחזר, במחיר של שעות עבודה של ה-CPU. dump של מסד הנתונים לבדו אינו משחזר דבר, כיוון שהוא מכיל רק מטא-דאטה.

עבור PhotoPrism, לאינדקס יש פקודה משלו.

docker compose exec photoprism photoprism backup -i -f

פקודה זו כותבת dump בפורמט SQL תחת storage/backup/. לאחר מכן העתיקו את התיקייה originals ואת התיקייה storage. מכיוון ש-PhotoPrism כותב גם קובצי YAML נלווים המתארים כל תמונה, ניתן לבנות מחדש אינדקס שאבד מתוך הקבצים בלבד; זהו יתרון משמעותי עבור ארכיון שאתם מתכננים לשמור במשך עשורים.

בלי קשר למה שתבחרו, שלחו את הגיבויים הללו מחוץ לשרת לפי לוח זמנים באמצעות גיבויי restic מוצפנים ומבוצעים דה-דופליקציה לאחסון מרוחק. גיבוי שנמצא על אותו דיסק כמו הספרייה אינו נחשב לגיבוי.

באיזו אפשרות כדאי לבחור

הריצו את Immich אם התמונות שלכם נמצאות בטלפונים, אם יותר מאדם אחד צריך לגבות את גלריית התמונות, ואם באפשרותכם להקצות לשרת 6 GB של RAM או יותר. זהו הפתרון הקרוב ביותר ל-Google Photos שניתן לארח באופן עצמאי, והחוויה במכשירים ניידים היא לב העניין. מדריך ההתקנה המפורט שלנו ל-Immich מכסה בהרחבה את נושא קריסות הזיכרון ומלכודות השדרוג.

הריצו את PhotoPrism אם כבר יש לכם ארכיון תמונות על הדיסק, אם חשובים לכם מפות, מטא-דאטה ושמירה על מבנה התיקיות שלכם, או אם ל-VPS שלכם יש 4 GB של RAM ואתם מעדיפים ספרייה מתפקדת על פני כזו שסובלת מ-swapping. זהו כלי טוב יותר לארגון וסינון תמונות, והוא דורש פחות משאבי חומרה.

הרצה של שניהם במקביל היא גם אפשרות סבירה. Immich מטפל בקליטת התמונות היומית מהטלפון, ופעם בשנה אתם ממיינים את התמונות שברצונכם לשמור אל תוך הארכיון שלכם ונותנים ל-PhotoPrism לאנדקס אותו. הם אינם מתנגשים, כיוון ש-PhotoPrism קורא תיקיות בעוד ש-Immich מנהל את התיקיות שלו באופן עצמאי.

FAQ

האם PhotoPrism ו-Immich יכולים לשתף את אותה תיקיית תמונות?

לא בצורה בטוחה בשני הכיוונים. PhotoPrism קורא מתיקיית originals וכותב קובצי sidecar בפורמט YAML לצד התמונות, בעוד ש-Immich מצפה להיות הבעלים הבלעדי של תוכן תיקיית ההעלאות שלו. ניתן להפנות את PhotoPrism לעותק לקריאה בלבד של תיקיית ה-library של Immich לצורך צפייה, אך אין לאפשר לשני היישומים לנהל את אותם קבצים, כיוון שתבנית האחסון של Immich עלולה להעביר או לשנות שמות של נכסים בזמן ש-PhotoPrism מבצע אינדוקס.

האם Immich יציב מספיק כדי להחזיק את העותק היחיד של התמונות שלי?

אף יישום בניהול עצמי (self-hosted) לא אמור להחזיק את העותק היחיד של שום דבר. Immich מפיץ שינויים שוברים לעיתים קרובות, ו-docker compose pull לא זהיר עלול להוביל למצב שבו מסד הנתונים לא יצליח לעלות; לכן, קבעו גרסה ספציפית וקראו את הערות השחרור לפני כל שדרוג. שמרו על גיבוי של הקבצים המקוריים מחוץ לשרת, וכך הסיכון יישאר נמוך.

מדוע מכולת הלמידה החיסונית (machine learning) של Immich מאתחלת את עצמה שוב ושוב?

היא נסגרת בכוח בגלל צריכת זיכרון גבוהה מדי. הריצו את docker compose ps וחפשו שירות למידת מכונה שיוצא עם קוד 137, המעיד על כך ש-kernel out of memory killer סיים את התהליך. הוסיפו swap, הגדירו מגבלת זיכרון למכולה כדי שתואט במקום להיסגר, או השביתו את הלמידה החיסונית לחלוטין אם מדובר במכונה עם 4 GB זיכרון. החיפוש יפסיק לעבוד בלעדיה, אך שאר היישום ימשיך לפעול כראוי.

האם PhotoPrism זקוק ל-MariaDB, או ש-SQLite יספיק?

SQLite עובד ומתאים לספריות אישיות, אך PhotoPrism מגביל את עצמו לארבעה עובדים (workers) בעבודה מולו. התיעוד ממליץ לעבור ל-MariaDB כיוון שהוא מתמודד טוב יותר עם עומס בו-זמני גבוה. קובץ ה-compose שהפרויקט מפיץ כבר כולל MariaDB, ולכן המסלול המומלץ הוא גם ברירת המחדל.

כמה שטח דיסק עליי לתקצב מעבר לנפח הספרייה שלי?

הוסיפו 10 עד 20 אחוזים מעבר לנפח המקורי של הקבצים עבור כל אחד מהיישומים. תוספת זו מכסה יצירת תמונות ממוזערות (thumbnails) ותצוגות מקדימות של וידאו שעברו קידוד. עבור אוסף של 200 GB, כדאי להקצות נפח של כ-300 GB כדי להשאיר מקום למסד הנתונים, לעותק גיבוי מקומי ולצמיחה עתידית.