Noodle Gallery zamiast Immich i Google Photos: czym nowy fork Immicha różni się od oryginału, jak przenieść bibliotekę bez kopiowania zdjęć i dla kogo funkcje Shared Spaces, S3 oraz rozpoznawanie twarzy są warte migracji

Jeśli biblioteka w Immich ma już kilkadziesiąt tysięcy zdjęć, rozpoznane twarze, albumy i działający backup z telefonów, ostatnią rzeczą, jakiej chce administrator, jest ponowny import kilku terabajtów danych. I właśnie tu Noodle Gallery jest nietypowe. To nie konkurencyjna aplikacja, do której trzeba „przeprowadzić” zdjęcia, lecz fork Immicha zachowujący zgodność z jego bazą danych, katalogiem plików i API.

W praktyce przejście z działającego Immicha może więc nie wymagać skopiowania ani jednego JPEG-a czy filmu. Zmienia się aplikacja obsługująca istniejącą bibliotekę, a nie sama biblioteka. Jednocześnie Gallery dokłada funkcje, których w upstreamowym Immichu nie ma lub które rozwiązano tam inaczej: Shared Spaces, Global People, rozbudowane filtrowanie, pamięć S3 jako natywny backend, import Google Takeout, rozszerzone narzędzia do twarzy, workflow i funkcje współdzielenia dużych bibliotek.

Nie oznacza to automatycznie, że każdy użytkownik Immicha powinien migrować. Fork ma mniejszą społeczność, więcej własnego kodu i dodatkowe migracje bazy danych. Jeżeli zdjęcia obsługuje jedna osoba, biblioteka leży na lokalnym dysku, a Partner Sharing i zwykłe albumy wystarczają, upstreamowy Immich pozostaje prostszym wyborem. Gallery zaczyna mieć sens wtedy, gdy ograniczenia Immicha są już konkretnym problemem, a nie pozycją na liście funkcji.

Noodle Gallery nie zastępuje fundamentu Immicha — dokłada warstwę, której upstream nie ma

Noodle Gallery określa się jako „friendly fork”. To istotne rozróżnienie. Projekt nie odciął się od Immicha i nie rozwija całkowicie osobnej platformy. Kod jest regularnie synchronizowany z upstreamem, a we wrześniu 2026 r. aktualna gałąź Gallery bazuje już na Immich v3.1.0. Równolegle rozwijana jest linia Noodle Gallery v5; 5 września pojawiło się v5.6.0-rc.0, czyli wydanie przedprodukcyjne, a nie wersja, którą bez testu warto wstawiać na rodzinny serwer z jedyną kopią zdjęć.

To ważne również operacyjnie. Aktualizowanie forka nie polega na czekaniu miesiącami na ręczne przeniesienie zmian z Immicha. Założeniem projektu jest rebase na kolejne wydania upstreamu, zwykle z kilkudniowym odstępem. Ceną jest oczywiście dodatkowa warstwa ryzyka: każda większa zmiana Immicha musi zostać pogodzona z kodem Shared Spaces, S3, Global People i pozostałych dodatków.

Najbardziej zauważalne różnice nie dotyczą samego wyświetlania galerii, lecz sposobu organizacji kilku użytkowników.

Shared Spaces są czymś więcej niż współdzielonym albumem. Każdy użytkownik zachowuje własne konto oraz własność swoich zdjęć, natomiast zdjęcia trafiają do wspólnej przestrzeni przez referencję. Plik nie jest kopiowany do kolejnego katalogu. Jedno zdjęcie może należeć do biblioteki użytkownika i jednocześnie pojawiać się w przestrzeni „Rodzina”, „Wakacje 2026” czy „Klienci”, bez mnożenia zajętego miejsca.

Dostęp dzieli się na trzy role:

• Owner — zarządza przestrzenią, jej członkami i zawartością,
• Editor — może współtworzyć i porządkować kolekcję,
• Viewer — ma dostęp do przeglądania bez możliwości przypadkowego przebudowania przestrzeni.

Do tego dochodzi osobna oś czasu, historia aktywności, wyszukiwanie, mapa, ludzie i albumy wewnątrz Shared Space. Każdy członek może zdecydować, czy zdjęcia ze Space mają pojawiać się również na jego głównej osi czasu.

To rozwiązuje problem dobrze znany z rodzinnego Immicha. Partner Sharing działa wygodnie dla dwóch osób, ale jest rozwiązaniem szerokim: udostępnia się bibliotekę partnerowi, zamiast tworzyć precyzyjnie wydzieloną, wieloosobową bibliotekę. Album z kolei nadal ma właściciela i jest przede wszystkim kolekcją zdjęć, a nie wspólnym środowiskiem pracy.

Przy kilku użytkownikach różnica szybko przestaje być kosmetyczna. Rodzice, dzieci i dziadkowie mogą wrzucać fotografie do jednej przestrzeni, ale nadal posiadać osobne biblioteki i konta.

Gallery rozwiązuje również problem bardzo dużych kolekcji. Funkcja dodania wszystkich wyników bieżącego filtra pozwala jednym działaniem dołączyć do albumu lub Space do 50 000 zdjęć. Przy zewnętrznej bibliotece lepsza jest funkcja Connected Libraries: można podpiąć bibliotekę do przestrzeni referencyjnie, dzięki czemu nowe fotografie pojawiają się tam bez tworzenia drugiego zestawu plików.

Drugą istotną zmianą jest Global People. W Immichu rozpoznawanie osób jest powiązane z biblioteką użytkownika. Ta sama babcia może więc istnieć jako jedna osoba u właściciela serwera, druga u partnera i kolejna w innym kontekście udostępniania. Gallery buduje wspólną warstwę tożsamości nad osobistą biblioteką i dostępnymi Shared Spaces.

Nie oznacza to obejścia uprawnień. System nie powinien pokazać użytkownikowi zdjęcia tylko dlatego, że rozpoznał na nim osobę znaną z innego Space. Global People scala tożsamość w granicach danych, do których użytkownik już ma dostęp.

Do tego dochodzą Face Suggestions oraz narzędzia porządkowania twarzy. To praktyczny dodatek przy bibliotekach liczących dziesiątki lub setki tysięcy fotografii, ponieważ model rozpoznawania twarzy celowo pracuje z dość zachowawczym progiem. Fałszywe przypisanie twarzy jest gorsze niż pominięcie: błędna osoba później pojawia się w wyszukiwaniu, wspomnieniach i filtrach. Gallery potrafi pokazywać przypadki znajdujące się blisko progu rozpoznania i oddać decyzję użytkownikowi.

Samo ML nadal działa lokalnie. Do sensownej instalacji producent wskazuje minimum 2 rdzenie CPU i 4 GB RAM, natomiast przy funkcjach machine learning rozsądniejszym minimum jest 6 GB RAM lub więcej. Akcelerację można oprzeć na obrazach przeznaczonych dla NVIDIA CUDA, AMD ROCm albo Intel OpenVINO. Przy pierwszym przetwarzaniu kilkudziesięciu tysięcy zdjęć robi to dużą różnicę — szczególnie przy generowaniu embeddingów i analizie twarzy.

Migracja z Immicha bez kopiowania zdjęć jest prosta, ale nie wolno pominąć kopii PostgreSQL

Największym technicznym atutem Gallery jest sposób migracji. Nie eksportuje się biblioteki z Immicha i nie importuje jej ponownie. Nie trzeba też budować jeszcze raz struktury albumów ani przenosić plików na drugi wolumin.

Gallery korzysta z tego samego układu uploadów i tej samej bazy. Typowa migracja istniejącej instalacji sprowadza się do trzech zmian.

W docker-compose.yml obraz serwera:

ghcr.io/immich-app/immich-server:${IMMICH_VERSION:-release}

zastępuje:

ghcr.io/open-noodle/gallery-server:${IMMICH_VERSION:-release}

Obraz machine learning:

ghcr.io/immich-app/immich-machine-learning:${IMMICH_VERSION:-release}

zastępuje:

ghcr.io/open-noodle/gallery-ml:${IMMICH_VERSION:-release}

Natomiast w .env zamiast przykładowego:

IMMICH_VERSION=release

ustawia się linię Gallery, obecnie:

IMMICH_VERSION=v5

Następnie obrazy można pobrać i kontenery odtworzyć poleceniem:

docker compose pull && docker compose up -d

To właśnie dlatego wielkość biblioteki nie przekłada się bezpośrednio na czas kopiowania. Dwa terabajty zdjęć pozostają w tym samym miejscu. Gallery uruchamia się nad tą samą bazą i plikami.

Jest jednak krok ważniejszy od wszystkich powyższych: przed zmianą trzeba wykonać pełny backup PostgreSQL, najlepiej pg_dumpall, i upewnić się, że kopia rzeczywiście da się odczytać. Backup samego katalogu z JPEG-ami nie wystarczy. Albumy, użytkownicy, twarze, informacje ML, ustawienia i relacje między zasobami znajdują się w bazie.

Najbezpieczniejsza kolejność jest więc taka:

1. zatrzymać automatyczne aktualizacje stosu,
2. wykonać kopię PostgreSQL,
3. zapisać aktualny docker-compose.yml i .env,
4. zanotować dokładną wersję Immicha,
5. podmienić obrazy i wersję,
6. uruchomić Gallery,
7. sprawdzić liczbę zdjęć, albumy, użytkowników, twarze, filmy oraz działanie backupu mobilnego,
8. dopiero wtedy zacząć używać funkcji specyficznych dla Gallery.

Ostatni punkt ma znaczenie, jeśli test ma być odwracalny. Gallery dodaje do bazy własne tabele, kolumny i wpisy migracji. Powrót nie powinien więc polegać na brutalnej podmianie obrazu Dockera z powrotem na Immich.

Projekt dostarcza skrypt czyszczący elementy specyficzne dla Gallery. Dopiero po jego wykonaniu powinno się przywrócić obrazy ghcr.io/immich-app/immich-server i ghcr.io/immich-app/immich-machine-learning. Zdjęcia i filmy nadal pozostają nietknięte.

To najczęstszy błąd, którego warto uniknąć: kompatybilność plików nie oznacza, że można ignorować wersję schematu bazy danych.

Jeszcze inaczej wygląda przeprowadzka z Google Photos. Tutaj fizycznego transferu danych nie da się ominąć, bo fotografie znajdują się na infrastrukturze Google. Gallery ma własny kreator importu Google Takeout i obsługuje między innymi:

• daty,
• współrzędne GPS,
• opisy,
• oznaczenie ulubionych,
• strukturę albumów,
• pliki .supplemental-metadata.json,
• warianty edytowane przez Google Photos,
• lokalizowane nazwy katalogów Takeout.

To znacznie wygodniejsze niż ręczne składanie fotografii i sidecarów skryptami, ale nadal trzeba najpierw pobrać archiwum Takeout. Przy bibliotece 500 GB potrzebne jest więc realnie miejsce na eksport i czas na transfer. W przypadku migracji Immich → Gallery ten etap nie istnieje.

Google Photos pozostaje wygodniejsze, jeśli użytkownik nie chce administrować serwerem. Konto Google daje 15 GB wspólnego bezpłatnego miejsca dla Gmaila, Dysku i Zdjęć, po czym trzeba przejść na płatny Google One. Noodle Gallery nie ma limitu pojemności narzuconego przez aplikację ani opłaty abonamentowej za funkcje — projekt jest udostępniany na licencji AGPL-3.0 — ale koszt nie znika. Zamiast abonamentu Google płaci się za dyski, kopię zapasową, prąd, ewentualny VPS, domenę i czas administratora.

Immich również pozostaje funkcjonalnie bezpłatny. Oferowane klucze wspierające rozwój kosztują obecnie 25 USD dla pojedynczego użytkownika oraz 100 USD dla całej rodziny, ale nie odblokowują funkcji i nie są wymagane do korzystania z programu.

Shared Spaces, S3 i rozpoznawanie twarzy są argumentem za migracją tylko przy konkretnym sposobie użycia

Najmocniejszym argumentem za Noodle Gallery nie jest liczba funkcji, lecz trzy przypadki, w których architektura zwykłego Immicha zaczyna przeszkadzać.

Pierwszy to rodzinny lub zespołowy serwer z kilkoma niezależnymi użytkownikami. Jeżeli każdy robi zdjęcia własnym telefonem, a wszyscy chcą wspólnej osi czasu dzieci, podróży lub wydarzeń, Shared Spaces są znacznie naturalniejsze od przekazywania sobie całych bibliotek albo tworzenia kolejnych albumów.

W przypadku jednego użytkownika przewaga praktycznie znika. Nie ma sensu przyjmować ryzyka forka tylko po to, by mieć funkcję przestrzeni, z której nikt nie będzie korzystał.

Drugi przypadek to bardzo duża biblioteka i storage, który ma rosnąć niezależnie od serwera aplikacyjnego. Gallery obsługuje S3 jako natywny backend nowych plików. Może współpracować między innymi z AWS S3, MinIO, Cloudflare R2, Backblaze B2 i Wasabi.

Podstawowa konfiguracja wymaga między innymi:

IMMICH_STORAGE_BACKEND=s3

oraz określenia bucketu, regionu, endpointu i danych dostępowych. Dla AWS można zamiast statycznych kluczy wykorzystać standardowy mechanizm IAM.

Istnieją dwa sposoby serwowania obiektów:

• redirect — Gallery autoryzuje żądanie i odsyła klienta tymczasowym, podpisanym URL-em; domyślny czas ważności takiego adresu wynosi 3600 sekund,
• proxy — plik przepływa przez serwer Gallery.

Dla dużej instalacji lepszy jest zwykle redirect, bo serwer aplikacyjny nie musi przepychać każdego zdjęcia i filmu. Ma to jednak konsekwencję: przeglądarka musi być w stanie dotrzeć bezpośrednio do endpointu S3.

Jeżeli MinIO działa wyłącznie pod adresem typu http://minio:9000 wewnątrz sieci Docker Compose, komputer użytkownika takiego hosta nie zna. Wtedy trzeba użyć proxy albo wystawić S3 pod poprawnym adresem.

Przy redirect trzeba również poprawnie skonfigurować CORS. Typowa pułapka wygląda tak: zwykłe zdjęcia otwierają się, więc administrator uznaje konfigurację za poprawną, ale później przestaje działać edycja, crop twarzy, operacja na canvasie albo część obsługi filmów. Powodem jest brak odpowiednich nagłówków CORS na bucketcie.

Gallery potrafi też przenieść istniejące dane między dyskiem a S3. Narzędzie Storage Migration działa w obu kierunkach, wylicza przed rozpoczęciem liczbę plików i szacowaną objętość, pozwala wybrać typy plików, domyślnie używa 5 równoległych operacji, a przerwaną migrację można wznowić. Operacja jest idempotentna, więc ponowne uruchomienie pomija już przeniesione dane. Każda migracja dostaje również batch ID umożliwiający rollback.

To dużo bezpieczniejsze niż jednorazowe rclone move wykonane na żywej bibliotece, szczególnie gdy w tym samym czasie telefony nadal wysyłają nowe zdjęcia.

Trzeci powód migracji to rozpoznawanie osób w środowisku wieloużytkownikowym. Sam Immich już bardzo dobrze wykrywa twarze, więc migrowanie tylko dla hasła „face recognition” nie ma sensu. Różnicę robi dopiero Global People oraz rozpoznawanie w Shared Spaces.

Przykład jest banalny. Trzy osoby mają zdjęcia tego samego dziecka. W modelu bibliotek rozdzielonych dostajemy trzy zbiory i trzy tożsamości. W Gallery wspólna warstwa ludzi pozwala przeszukiwać dostępne przestrzenie tak, jakby chodziło o jedną osobę. Przy rodzinnej bibliotece obejmującej 10–15 lat fotografii jest to znacznie bardziej użyteczne niż kolejny algorytm klasyfikujący pojedyncze twarze.

Do tego dochodzą filtry po osobach, lokalizacji, aparacie, tagach i datach, wyszukiwanie kontekstowe, globalna paleta Cmd/Ctrl+K, rozszerzone wspomnienia oraz workflow mogące automatycznie dodawać pasujące nowe zdjęcia bezpośrednio do Shared Space lub jego albumu.

Nie wszystko zasługuje jednak na migrację od razu. Noodle Gallery ma mniejszą bazę użytkowników i testerów niż Immich. Im więcej własnych dodatków wykorzystuje instalacja, tym więcej trzeba sprawdzić po aktualizacji. Szczególnie ostrożnie podchodziłbym do wersji oznaczonych rc, jeżeli serwer przechowuje rodzinne archiwum i nie ma osobnego środowiska testowego.

Dla większości domowych wdrożeń hierarchia decyzji jest prosta:

• zostań przy Immich, jeśli masz jednego lub dwóch użytkowników, lokalny storage i obecne udostępnianie nie ogranicza pracy;
• wypróbuj Gallery, jeżeli faktycznie potrzebujesz wspólnej wieloosobowej osi czasu, rozpoznawania osób ponad bibliotekami albo natywnego S3;
• zostań przy Google Photos, jeśli nie chcesz odpowiadać za backup bazy, aktualizacje Dockera, TLS, dyski, monitoring i odtwarzanie po awarii.

Self-hosting nie zwalnia z robienia kopii zapasowej. RAID nie jest backupem, S3 również nie staje się backupem tylko dlatego, że znajduje się poza serwerem. Skasowanie pliku przez aplikację może zostać poprawnie zsynchronizowane z backendem. Dla ważnej biblioteki nadal potrzebna jest druga niezależna kopia, najlepiej zgodna z zasadą 3-2-1.

Więcej na ten temat na stronie: https://itux.pl

FAQ

Czy podczas przejścia z Immicha do Noodle Gallery wszystkie zdjęcia są kopiowane?
Nie. Gallery korzysta z tej samej bazy danych i tych samych plików. Zmieniane są obrazy kontenerów i wersja aplikacji. Dlatego biblioteka o wielkości 2 TB nie wymaga wykonania kolejnej kopii 2 TB tylko na potrzeby migracji.

Czy przed migracją trzeba wykonać backup?
Tak. Priorytetem jest pełna kopia PostgreSQL, a nie tylko katalogu ze zdjęciami. W bazie znajdują się między innymi użytkownicy, albumy, relacje zdjęć, twarze i część danych generowanych przez aplikację.

Czy można później wrócić do Immicha?
Tak, ale najpierw trzeba usunąć z bazy elementy specyficzne dla Gallery za pomocą dostarczonego mechanizmu switch-back. Samo przestawienie obrazów Docker z powrotem na Immich nie jest prawidłową procedurą rollbacku.

Czy Noodle Gallery jest płatne?
Nie. Serwer jest projektem open source na licencji AGPL-3.0 i nie ma abonamentu ani limitu pojemności narzuconego przez aplikację. Użytkownik ponosi natomiast koszt własnego sprzętu, storage, energii, hostingu i kopii zapasowej.

Czy Noodle Gallery jest lepsze od Google Photos?
Nie dla każdego. Daje większą kontrolę nad danymi, brak narzuconego limitu pojemności, lokalne funkcje ML, Shared Spaces i możliwość użycia własnego S3. Google Photos wygrywa tym, że użytkownik nie administruje serwerem, aktualizacjami ani backupem infrastruktury.

Czy można przenieść bibliotekę z Google Photos?
Tak. Gallery ma kreator importu Google Takeout obsługujący zdjęcia oraz związane z nimi metadane, w tym daty, GPS, ulubione, opisy i strukturę albumów. W przeciwieństwie do przejścia z Immicha dane trzeba jednak najpierw fizycznie wyeksportować z Google.

Czy S3 jest obowiązkowe?
Nie. Standardowy lokalny filesystem nadal jest najprostszą konfiguracją. S3 warto wdrożyć, gdy storage ma być oddzielony od serwera, biblioteka szybko rośnie albo infrastruktura już korzysta z MinIO, AWS S3, R2, B2 czy Wasabi.

Czy do rozpoznawania twarzy potrzebna jest karta graficzna?
Nie. Machine learning działa także na CPU. Przy dużej bibliotece GPU lub akceleracja Intel OpenVINO skracają jednak czas pierwszego przetwarzania. Producent podaje minimum 4 GB RAM dla serwera, ale dla instalacji intensywnie korzystającej z ML sensowniej zaczynać od co najmniej 6 GB.

Czy warto instalować najnowsze wydanie RC?
Nie na jedynym produkcyjnym serwerze z ważną biblioteką. Wydanie rc jest kandydatem do wersji finalnej i służy między innymi do wychwytywania błędów przed stabilnym wydaniem. Na serwerze rodzinnym lepiej przypiąć sprawdzony tag i aktualizować dopiero po wykonaniu backupu.

Pierwszy krok nie powinien więc polegać na instalowaniu Gallery. Najpierw wykonaj pg_dumpall istniejącej bazy Immicha i sprawdź, czy kopia ma sensowny rozmiar oraz daje się odczytać. Następnie zapisz wersję Immicha, docker-compose.yml i .env. Dopiero z takim punktem powrotu podmień trzy linie konfiguracji i uruchom Gallery na tej samej bibliotece. Shared Spaces, S3 i Global People warto włączać dopiero po sprawdzeniu, że zwykłe zdjęcia, albumy, filmy, użytkownicy i backup mobilny działają dokładnie tak jak przed migracją.