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 מחר, התמונות יישארו שם באותן תיקיות עם אותם שמות, וקבצי ה־YAML הצדדיים ש־PhotoPrism כתבה כדי לתאר את מה שלמדה יישארו בתיקיית האחסון שלה, המקום שבו היא שומרת אותם כברירת מחדל.

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

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

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

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

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; זהו הסטטוס לתהליך שנהרג עם signal 9, הדרך שבה Docker מציג סגירה עקב מחסור בזיכרון (OOM kill). המודלים המובנים של PhotoPrism רצים על ONNX, שלפי התיעוד שלהם מתפקדים היטב על כל סוגי החומרה, ויש להם מנגנון חלופי לזיכרון מוגבל: במכונות עם 1 GB או פחות, המערכת משביתה המרת RAW וזיהוי פנים. עם זאת, זו אינה ערובה ליציבות. מתחת לרף ה-3 GB המינימלי, הפרויקט מזהיר מפני חוסר יציבות ובעיות ביצועים, לכן יש להתייחס לרף זה כאל הגבול התחתון.

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

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 היא הדרך למנוע משירות רעב אחד להפיל את כל השרת. היוצא מן הכלל הוא PhotoPrism עצמו: התיעוד שלו ממליץ שלא להגדיר מגבלת זיכרון קשיחה למכולה שלו, כיוון שאינדוקס קבצים גדולים דורש לזמן קצר זיכרון נוסף, ומגבלה עלולה לגרום לאתחולים בלתי צפויים.

דרישה נוספת מפתיעה משתמשים רבים. מסד הנתונים Postgres של Immich חייב לשבת על מערכת קבצים Unix רגילה עם בעלות והרשאות תקינות, על אחסון מקומי, ולעולם לא על כונן רשת. PhotoPrism מזהיר שלא לאחסן את קובצי מסד הנתונים שלו בתיקיית רשת משותפת ומגדיר אחסון SSD מקומי כמקום הטוב ביותר עבורם. אף אחד מהיישומים אינו בטוח להרצה כאשר מסד הנתונים שלו נמצא על 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 מגיע עם ברירת מחדל תקינה, ו-Immich ממליצה לשנות אותה לסיסמה אקראית, אם כי הדבר אינו מחייב. מסד הנתונים Postgres אינו חשוף לציבור, לכן הסיסמה משמשת לאימות מקומי בלבד, אך אין עלות בשימוש בסיסמה אקראית. השתמש רק בתווים A-Za-z0-9, כיוון שהתיעוד של Immich מציין שתווים אחרים עלולים לגרום לבעיות בעת ש-Docker מנתח את הערך. לאחר מכן, הפעל את השירות.

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 וגיבויים, או שמור על השרת פרטי וגש אליו דרך VPN. אם ה-VPS הזה יארח בסופו של דבר יותר מאשר רק תמונות, החל את אותה ריסון על כל שירות שתוסיף לו, כיוון ש-ממסר RustDesk בניהול עצמי דורש שרק שני הפורטים שלו יהיו נגישים ולא שום דבר אחר.

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

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

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

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

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

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

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

PhotoPrism מסווגת תמונות לתוויות באמצעות מודל ONNX מובנה, מזהה פנים ומקבצת אותן לאנשים באמצעות מודלי פנים של ONNX, וקוראת מטא-דאטה של מיקום כדי לבנות מפת מקומות. קובץ vision.yml בתיקיית התצורה שלה מאפשר להחליף את המנוע ב-Ollama או ב-OpenAI עבור תוויות וכיתובים, אם תרצו בכך. המפה היא התכונה שבזכותה משתמשים נשארים: ספרייה שמקוטלגת לפי המקום שבו הדברים קרו היא דרך שונה באמת לעיין בעשרים שנה של תמונות. אותו רעיון עובד על אוספי מדיה אחרים, ו-ממשק ה-front end של Halcyon בסגנון חנות וידאו משנות ה-90 עבור Jellyfin הוא הגרסה הקולנועית לכך, המאפשרת עיון לפי מדפים במקום לפי רשימות. זיהוי פנים כלול במהדורת ה-Community החינמית. מנויי ה-Essentials וה-Plus בתשלום מוסיפים תוספות כגון שכבות מפה עשירות יותר, תפקידי משתמש נוספים וממשק ניהול משתמשים, החל מכמה אירו לחודש, בחיוב שנתי, נכון לאוקטובר 2026.

ל-Immich אין תכונות החסומות מאחורי חומת תשלום, והפרויקט מצהיר כי לעולם לא יהיו. הוא אכן מוכר מפתחות מוצר אופציונליים לכל החיים, 25 דולר למשתמש יחיד או 100 דולר לשרת שלם לפי המחירים ש-Immich הכריזה עליהם ביולי 2024, אך רכישת מפתח אינה פותחת דבר ו-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 מוצפנים וללא כפילויות לאחסון מרוחק. גיבוי שנמצא באותו דיסק שבו נמצאת הספרייה אינו גיבוי. הגדירו למשימה לשלוח התראה במקרה של כשל, משום שגיבוי שהפסיק לפעול בשקט במרץ נראה בדיוק כמו גיבוי שפעל אמש — עד היום שבו תזדקקו לו. שרת ntfy באירוח עצמי ישלח את הכשל לטלפון שלכם עוד באותו ערב.

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

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

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

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

FAQ

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

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

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

אף יישום בניהול עצמי (self-hosted) לא אמור להחזיק את העותק היחיד של שום דבר. Immich עוקב כעת אחר גרסאות סמנטיות (semantic versioning) ומצהיר ששינויים שוברים מוגבלים לגרסאות ראשיות (major releases), לכן יש לקבע (pin) את IMMICH_VERSION לתגית גרסה ראשית כמו v3, לקרוא את הערות השחרור, ורק אז לשדרג באמצעות docker compose pull && docker compose up -d. חזרה לגרסה קודמת (downgrade) אינה נתמכת, גם לא בתוך אותה גרסה משנית, לכן יש לבצע גיבוי של מסד הנתונים לפני כל שדרוג. שמרו על הקבצים המקוריים מגובים מחוץ לשרת, והסיכון יישאר נמוך.

מדוע מכולת (container) הלמידה החישובית של Immich ממשיכה לבצע אתחול מחדש?

בדרך כלל היא נסגרת (killed) עקב צריכת זיכרון גבוהה מדי. הריצו את docker compose ps --all, כיוון שמכולה שנעצרה מוסתרת ללא דגל זה, וחפשו שירות למידה חישובית שנסגר עם קוד 137. קוד זה מציין שהתהליך נסגר עם אות (signal) 9; מנגנון ה-out of memory killer של ה-kernel הוא הסיבה הנפוצה לכך, אך לא היחידה, לכן יש לאמת זאת עם sudo dmesg | grep -i 'out of memory'. הוסיפו swap, או השביתו את הלמידה החישובית לחלוטין במכונה עם 4 GB זיכרון. הגבלת זיכרון על המכולה לא מאטה אותה: בהגעה למגבלה היא עדיין תיסגר, אך היא תפסיק להרעיב את שאר השרת. חיפוש חכם וזיהוי פנים יפסיקו לעבוד ללא למידה חישובית, אך שאר היישום Immich ימשיך לעבוד כראוי.

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

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

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

הוסיפו 10 עד 20 אחוזים מעבר לגודל הקבצים המקוריים, עבור כל אחד מהיישומים. תוספת זו מכסה תמונות ממוזערות (thumbnails) שנוצרו ותצוגות מקדימות של וידאו שעברו קידוד מחדש (transcoded). אוסף של 200 GB דורש בערך 220 עד 240 GB עבור הספרייה בלבד, בתוספת מקום למסד הנתונים ולצמיחה עתידית. אם אתם שומרים גם עותק גיבוי מקומי מלא על אותו כונן, הקבצים המקוריים והעותק דורשים לפחות 400 GB לפני שסופרים כל דבר אחר, לכן תקצבו סביב 450 GB או הציבו את העותק על כונן נפרד.