PhotoView

PhotoView — self-hosted веб-галерея для фотографий и видео, рассчитанная прежде всего на уже существующую медиатеку на NAS, домашнем сервере или файловом хранилище. Программа не строит отдельную систему папок поверх коллекции: она сканирует доступные ей каталоги, отображает директории как альбомы, создаёт миниатюры и служебные версии в собственном кэше и оставляет исходные файлы на их прежних местах. Такой подход нужен фотографам, владельцам семейных архивов и администраторам личных серверов, которым важно сохранить файловую структуру как главный способ организации коллекции, но получить удобные Timeline, Albums, Places и People, просмотр EXIF, обработку RAW, веб-оптимизацию видео и ссылки для общего доступа.

Что именно представляет собой PhotoView

Название PhotoView встречается у нескольких несвязанных продуктов, поэтому для этой программы важна точная идентификация. Здесь рассматривается серверная фотогалерея из проекта photoview/photoview: веб-приложение с серверной частью на Go и браузерным интерфейсом, распространяемое как открытый проект под лицензией GNU Affero General Public License v3.0. Оно не относится к Android-библиотеке для масштабирования изображений с тем же названием и не является настольным просмотрщиком картинок. Предмет обзора — именно галерея для self-hosted-сервера, которая индексирует медиа на файловой системе.

Архитектурная идея PhotoView формулируется через принцип «файловая система — источник истины». Альбом в интерфейсе соответствует каталогу на диске, а изменения структуры коллекции выполняются файловыми инструментами, которыми владеет пользователь: файловым менеджером, Samba, FTP, синхронизацией Nextcloud или другой системой, способной предоставить серверу обычные каталоги. PhotoView поверх этой структуры добавляет индекс, кэш, метаданные, миниатюры, лица, географическое представление и веб-доступ. Из-за этого программа ближе к визуальному слою над архивом, чем к классическому DAM, который импортирует файлы в собственную медиатеку и управляет ими внутри приложения.

Последним нумерованным релизом на 23 августа 2026 года остаётся 2.4.0. Ветка master развивается отдельно и получает автоматические контейнерные сборки с тегами master и sha-[commit]. Это различие принципиально: номер 2.4.0 нельзя автоматически переносить на изменения, уже присутствующие в текущей ветке разработки. Например, переход рекомендации на PostgreSQL 18 относится к master и будущему релизу; PostgreSQL 17 при этом продолжает поддерживаться.

Для кого предназначена программа

PhotoView особенно логичен для владельца NAS, у которого фотографии уже разложены по годам, поездкам, съёмкам, клиентам или семейным событиям. Вместо повторного импорта и построения второй системы каталогизации достаточно предоставить контейнеру чтение нужных корневых папок. После сканирования веб-интерфейс повторяет эту иерархию в Albums, а временная шкала строится по датам медиа. Такая модель хорошо сочетается с архивом, который одновременно используется через SMB, резервное копирование, синхронизацию и локальные редакторы.

Второй характерный сценарий — фотографический архив с RAW. PhotoView создаёт браузерные производные и миниатюры, а исходник сохраняет отдельно. Для RAW используется Darktable, для видео — FFmpeg, а EXIF извлекается и показывается в информационной панели. Релиз 2.4.0 отдельно добавил поддержку CR3 и исправил проблему с чтением EXIF из HEIC через ExifTool. Поэтому программа ориентирована не только на JPEG-архивы со смартфона, но и на коллекции с исходниками камер.

Третий сценарий — семейная медиатека с несколькими учётными записями. Для пользователя задаются один или несколько путей, которые он видит, а администратор управляет пользователями, паролями и сканированием. Один и тот же каталог разрешено пересекать между пользователями: общий файл обрабатывается сканером один раз, при этом избранное и публичные ссылки остаются индивидуальными для учётных записей. Такая схема позволяет дать родственникам доступ только к определённым частям общего хранилища без создания второй копии фотографий.

PhotoView хуже соответствует задачам, где само приложение должно быть главным файловым менеджером: загружать снимки с телефона как резервную копию, переносить и переименовывать оригиналы, массово редактировать содержимое архива или строить независимую от каталогов систему коллекций. Документированный рабочий процесс PhotoView исходит из обратного: файлы уже находятся в доступной папке, а программа индексирует и показывает их. Управление физической структурой остаётся за внешними инструментами.

Модель распространения, лицензия и состояние проекта

PhotoView распространяется бесплатно как открытое программное обеспечение под AGPL-3.0. У проекта нет обязательной коммерческой подписки для запуска собственного сервера. Реальные эксплуатационные затраты возникают на стороне владельца: сервер или NAS, место под кэш и базу, домен и обратный прокси для внешнего доступа, резервные копии и администрирование. Это важно отличать от облачной фотогалереи: программа не предоставляет готовое пользовательское хранилище как услугу, а устанавливается в инфраструктуру владельца.

Готовый релизный контейнер находится в реестре photoview/photoview. В актуальной документации отдельно отмечена миграция с старого реестра viktorstrate/photoview: прежние образы остаются доступными там, но новые сборки master и будущие релизы публикуются в новом пространстве. При обслуживании давно установленной системы это не косметическая деталь — в docker-compose.yml требуется использовать правильное имя образа, иначе администратор останется на старой схеме распространения.

Для тега 2.4.0 Docker Hub показывает два сжатых образа: 527,3 MB для linux/amd64 и 495,88 MB для linux/arm64. Теги latest, 2, 2.4 и 2.4.0 указывают на одинаковые релизные дайджесты. Отдельный master имеет другой дайджест и отражает текущую разработку. Поэтому для стабильной установки разумно фиксировать релизный тег, а master рассматривать как непронумерованную ветку с новыми изменениями и потенциальными миграциями.

Обычного публичного установщика Windows, macOS-пакета или единственного прямого HTTP-файла с готовой серверной программой проект не публикует. Рабочий путь готовой установки — получение контейнерного образа средствами Docker; альтернативный путь — сборка из исходников. Это причина, по которой карточка программы не должна подменять Docker Registry выдуманной «прямой ссылкой на EXE»: такого формата дистрибутива у PhotoView нет.

Интерфейс: Timeline, Albums, Places, People и Settings

Главная навигация вынесена в левую вертикальную панель. В документированном интерфейсе доступны Timeline, Albums, Places, People и Settings. Timeline показывает медиатеку в обратном хронологическом порядке, группируя изображения по дню съёмки. По мере прокрутки подгружаются новые строки, поэтому интерфейс не пытается отрисовать весь архив сразу. Сверху находится выбор периода Date и переключатель Show only favorites.

На скриншоте Timeline видно важное разделение интерфейса. Центральная область занята сеткой медиа, а справа открыта карточка выбранного файла: превью, сведения о камере и экспозиции, Album Path, варианты Download и Sharing options. Эта панель вызывается значком информации ⓘ. В самой сетке сердце отмечает избранное; фильтр сверху позволяет оставить только отмеченные кадры. Такое устройство делает основную операцию — просмотр большого архива — независимой от административных экранов.

Albums строится не из виртуальных коллекций, а из папок на сервере. Глубина вложения ограничивается файловой системой, а названия берутся из имён каталогов. Внутри альбома доступны сортировки Date shot, Date imported, Title и Kind, направление сортировки переключается стрелкой. Информационная панель медиа содержит команду установки изображения в качестве обложки альбома; кнопка с шестерёнкой у названия альбома открывает настройки общего доступа и загрузки.

Раздел Places использует координаты из EXIF. Фотографии с геотегами размещаются на карте, а близкие точки группируются. При выборе маркера пользователь переходит к фотографиям из этой области и переключает их стрелками. Для картографической функции в конфигурации предусмотрен MAPBOX_TOKEN; в релизе 2.4.0 отдельно появился глобусный вариант представления карты. Фотографии без координат в Places не возникают автоматически, потому что PhotoView не придумывает местоположение и использует сохранённые метаданные.

People появляется при включённом распознавании лиц. PhotoView сначала группирует найденные лица без имён, затем пользователь присваивает метки, объединяет дублирующиеся группы, отделяет ошибочно отнесённые лица и переносит их к нужному человеку. Это не полностью автоматическая адресная книга: программа определяет визуально похожие лица, а окончательная разметка остаётся под контролем владельца медиатеки.

Settings объединяет управление пользователями и сканером. В таблице пользователей видны Username, Photo path, Capabilities и Action; администраторам доступны Edit, Scan, Change password, Delete и New user. Photo path — путь внутри той среды, где работает PhotoView. Для Docker это означает путь внутри контейнера, а не произвольный абсолютный путь хоста. Именно несоответствие хостового и контейнерного путей — одна из типичных причин, по которой сканирование не находит фотографии.

После Edit одному пользователю разрешается назначить несколько путей. В файловом сканере действует ограничение: один путь одного пользователя не должен находиться внутри другого его пути, потому что это создало бы вложенное повторное сканирование. Пути разных пользователей разрешено пересекать. На административном экране флаг Admin даёт право запускать сканирование и управлять пользователями.

Периодический сканер включается отдельным переключателем Enable periodic scanner. Интервал задаётся числом и единицей времени. Рядом существует настройка количества concurrent workers — фоновых задач, обрабатываемых одновременно. Чем меньше значение, тем дольше обработка, но тем ниже пик нагрузки; для ограниченного оборудования документация прямо рекомендует значение 1.

Установка через Docker Compose

Актуальный основной путь установки начинается с Docker Engine и Docker Compose. Поддерживаемая политика для Docker сформулирована не через один фиксированный номер: движок должен быть выпущен в пределах последнего года, а его major-версия — не старше предыдущей основной версии. Проект отдельно предупреждает, что Portainer и другие уровни абстракции поверх Docker Compose не входят в поддерживаемый сценарий диагностики; проблему перед обращением предлагают воспроизводить на обычном Docker Compose.

В каталоге примеров есть два варианта Compose. docker-compose.example.yml — полнофункциональная конфигурация, рекомендуемая для большинства установок. docker-compose.minimal.example.yml — упрощённый вариант для тех, кому полный файл избыточен. Выбирается один, после чего файлы примера переименовываются так, чтобы рабочий каталог содержал .env, docker-compose.yml и при желании Makefile.

1. Подготовьте каталог, где будут храниться база данных, кэш и конфигурация PhotoView.
2. Возьмите содержимое каталога docker-compose example из проекта и выберите полный либо минимальный Compose-файл.
3. Переименуйте примеры в рабочие .env и docker-compose.yml; Makefile оставьте как вспомогательный инструмент управления.
4. Сначала прочитайте и настройте .env, затем docker-compose.yml, затем команды Makefile. Пароль MariaDB или PostgreSQL со специальными символами в строке подключения должен быть URL-кодирован.
5. Подключите каталог медиатеки как volume. Для безопасной модели исходники обычно достаточно предоставить на чтение; приложению требуется запись в собственный кэш и базу.
6. Проверьте права. Текущая Docker-инструкция использует UID/GID 999 в вариантах настройки доступа и предлагает команду make readable для корневого каталога медиа.
7. Запустите сервис командой make all либо эквивалентными командами из Makefile вручную.
8. При неизменённых порте и endpoint откройте http://localhost:8000.

make не является обязательным runtime-компонентом PhotoView: Makefile собран как удобная оболочка над командами. Если make не установлен, те же команды разрешается выполнять вручную после подстановки переменных из .env. Утилита 7zz нужна только для альтернативного сценария резервного копирования вместо формата .tar.xz, а не для обычного запуска галереи.

Первое открытие показывает мастер начальной настройки. Пользователь вводит имя и пароль администратора, затем указывает путь к фотографиям внутри контейнера. Путь по умолчанию — /photos, если Compose не изменён. После создания администратора библиотека ещё не заполнена: нужно открыть Settings и нажать Scan All. Только после сканирования Timeline и Albums получают медиаданные.

Не следует смешивать адреса из старой ручной инструкции и текущего Docker-сценария. Историческая ручная установка запускала сервер на другом локальном endpoint, а современный Compose по умолчанию публикует веб-интерфейс на порту 8000. При диагностике всегда нужно исходить из конфигурации конкретной установки, а не из случайного примера для другой ветки.

Выбор базы данных

SQLite встроен и не требует отдельного сервиса. Это упрощает небольшой личный инстанс, но текущая документация прямо характеризует его как вариант с самой низкой производительностью и без масштабируемости. Для большой медиатеки или нескольких активных пользователей эта простота сопровождается понятным компромиссом: база легче в обслуживании, но хуже подходит для роста.

MariaDB LTS названа выбором по умолчанию и балансом между производительностью и объёмом обслуживания. Она работает отдельным сервисом, поэтому резервное копирование и восстановление базы становятся самостоятельной административной задачей. PostgreSQL описан как вариант, обычно дающий лучшую производительность, но требующий чуть больше сопровождения.

Для PostgreSQL особенно важно различать релиз и ветку разработки. В текущем master проект перешёл на PostgreSQL 18 и оставил поддержку PostgreSQL 17; PostgreSQL 18 заявлен как рекомендуемая версия для следующего релиза. У PostgreSQL 18 изменён внутренний путь тома базы в контейнере на /var/lib/postgresql вместо прежнего /var/lib/postgresql/data. Поэтому обновление базы нельзя выполнять простым изменением номера образа без чтения соответствующей инструкции и резервной копии.

Первый рабочий процесс: от папки до готовой галереи

Базовый цикл PhotoView начинается не с загрузки файлов в веб-форму, а с подготовки каталога на сервере. Сначала фотографии и видео должны быть физически доступны ОС или контейнеру. Затем администратор связывает путь с пользователем. После этого сканер обходит каталоги, определяет медиа, читает метаданные, создаёт записи базы, формирует миниатюры и необходимые браузерные производные. В результате файловое дерево становится Albums, даты — Timeline, GPS-координаты — Places, а найденные лица — People.

1. Организуйте исходники. Окончательные папки лучше подготовить тем файловым инструментом, который уже используется для архива. PhotoView будет повторять эту структуру.
2. Смонтируйте медиатеку. Контейнер должен видеть каталог по пути, указанному в volume.
3. Назначьте Photo path. В мастере первого запуска или через Settings задайте путь внутри контейнера.
4. Запустите Scan All. Следите за логом контейнера, особенно на первой большой обработке.
5. Проверьте Timeline и Albums. Папки должны стать альбомами, а медиаданные — появиться в сетке.
6. Откройте ⓘ у нескольких файлов. Убедитесь, что дата, камера, путь альбома и варианты загрузки соответствуют исходникам.
7. Проверьте Places и People. Они зависят от GPS-метаданных и включённого распознавания лиц.
8. Настройте periodic scanner. Это поддерживает галерею в актуальном состоянии после появления новых файлов в каталогах.

Результат легко проверить без абстрактных «успешно». Если папка /photos/2026/Trip доступна назначенному пользователю, после сканирования соответствующая структура должна проявиться в Albums; новые фотографии с валидной датой должны попасть в Timeline; кадр с GPS — получить представление в Places; у файла с EXIF в боковой панели должны появиться метаданные. Отсутствие одного из этих результатов указывает на конкретный слой диагностики: монтирование, права, распознавание типа файла, метаданные или дополнительный инструмент обработки.

Сканирование и файловая модель

Сканер — центральный механизм PhotoView. Каждой учётной записи назначается набор путей, и при запуске сканер ищет медиа рекурсивно. Один пользователь не должен иметь корневой путь и одновременно вложенный в него второй путь: вложенный набор создавал бы дублирующий охват. Для разных пользователей пересечение путей допустимо. Общие файлы в этом случае обрабатываются один раз, чтобы кэш не разрастался копиями, но избранное и созданные публичные ссылки остаются пользовательскими.

PhotoView не переписывает оригиналы для построения библиотеки. Миниатюры и производные сохраняются в каталоге PHOTOVIEW_MEDIA_CACHE. Для файла, который браузер не умеет показать непосредственно, сканер дополнительно создаёт JPEG высокого разрешения; это характерно для RAW. Такой кэш отделён от исходной медиатеки. Он ускоряет интерфейс, но его объём растёт вместе с коллекцией и не должен считаться «временными несколькими мегабайтами».

Внутри медиапапок разрешено использовать .photoviewignore. Правила работают в стиле .gitignore и распространяются на каталог, где лежит файл, и его подпапки; более глубокие ignore-файлы объединяют правила. Практически это позволяет исключать технические каталоги, конкретные расширения или временные экспортные файлы без переноса содержимого из основного архива.

Просмотр, избранное и работа с отдельным файлом

В Timeline фотографии идут от новых к старым и сгруппированы по дням. При выборе файла открывается крупный просмотр; стрелки листают соседние элементы, а X возвращает в сетку. До полной загрузки высокого разрешения интерфейс показывает уже готовую миниатюру. Это особенно заметно на удалённом подключении к большим исходникам: пользователь быстрее получает визуальный контекст, даже когда оригинал ещё передаётся.

Сердце у миниатюры хранит персональное избранное. Фильтр Show only favorites сужает Timeline до отмеченных элементов. Эта функция не меняет файлы на диске и не создаёт отдельную папку; отметка живёт в данных PhotoView. Поэтому резервное копирование только исходных фотографий сохраняет сами снимки, но не гарантирует сохранность пользовательских меток, лиц и настроек — для этого нужна резервная копия базы.

Информационная панель ⓘ связывает просмотр с техническими сведениями. В ней показываются дата, камера, параметры экспозиции, Album Path, данные о распознанных лицах и местоположении при наличии, а ниже — Download и Sharing options. У загрузки есть оригинальная и уменьшенная версии; для альбома PhotoView умеет сформировать ZIP, эта возможность появилась в ветке 2.3.7. Такой экспорт не надо путать с резервным копированием: ZIP удобен получателю, но не заменяет серверный бэкап базы и медиатеки.

Поддерживаемые форматы, RAW, EXIF и видео

У PhotoView нет короткой рекламной таблицы «поддерживает сотни форматов» с гарантией каждого расширения. Логика разделена по способу обработки. Браузерные изображения, включая JPEG, PNG и GIF, обрабатываются напрямую. Небраузерные фото конвертируются в пригодную для веба производную; RAW проходит через Darktable. Видео, требующее преобразования, обрабатывает FFmpeg. Конкретная поддержка RAW зависит от Darktable и камеры, поэтому корректнее говорить о поддержке широкого набора RAW, а не обещать каждое проприетарное расширение.

Для пар RAW+JPEG предусмотрено обнаружение дубликата-пары: если соответствующие файлы лежат рядом, в галерее не требуется показывать две визуально одинаковые позиции. Сканер использует готовый JPEG вместо генерации новой версии RAW. Это снижает лишнюю обработку и соответствует распространённому фотографическому сценарию, где камера одновременно сохраняет RAW и JPEG.

EXIF извлекается для медиа и показывается рядом с выбранным файлом. В ручной установке ExifTool обозначен как необязательный внешний инструмент, который делает разбор метаданных быстрее и надёжнее; без него используется внутренний парсер. Географические координаты из EXIF питают Places, а дата съёмки влияет на Timeline и сортировку. Исправление 2.4.0 для HEIC показывает практическую границу: наличие формата и корректность метаданных — разные части пайплайна, поэтому после обновлений стоит проверять не только само превью, но и дату, камеру и геотег.

Распознавание лиц и раздел People

Распознавание лиц в PhotoView является опциональным. При отключении функции People скрывается из боковой навигации. При включении сканер находит лица и строит группы, но не знает имён людей. Первичная страница показывает группы с меткой Unlabeled и количеством фотографий; имя присваивает пользователь. Это снижает риск того, что автоматическое предположение будет выдано за достоверную личность.

Рабочий процесс корректировки состоит из четырёх операций. Change label задаёт имя группе. Merge face объединяет новый кластер с уже подписанным человеком. Detach face отделяет ошибочно попавшие фотографии обратно к неразмеченным. Move faces сочетает отделение и перенос к другой уже известной группе. Объединение способно заметно нагрузить сервер, поскольку переорганизация данных о лицах требует фоновой обработки.

Для большого семейного архива это означает, что People не является одноразовой кнопкой «распознать всех». После первоначального сканирования нужен этап валидации групп. Качество результата проверяется не числом найденных лиц, а просмотром нескольких групп, исправлением ложных объединений и контролем того, что один человек не разделён на слишком много кластеров. PhotoView предоставляет инструменты для этой ручной коррекции прямо в People.

Places и географическая навигация

Places строится только на реальных координатах, сохранённых в метаданных. Кадры без геотега не получают искусственную точку на карте. На обзорном масштабе близкие фотографии объединяются в кластеры, число на маркере показывает количество медиа из области. При увеличении масштаба географическое представление становится точнее, а выбор миниатюры открывает локальную последовательность снимков.

Функция полезна для телефонных фотографий, туристического архива и документальной съёмки, где GPS уже записывается камерой. Для отсканированных плёнок и старых семейных фотографий Places сам по себе не решает проблему отсутствующих координат: PhotoView не документирован как редактор геотегов. В таком архиве координаты требуется подготовить внешним инструментом до или вне PhotoView, а затем пересканировать медиатеку.

Картографическая конфигурация использует Mapbox token. В 2.4.0 добавлен глобусный вид Mapbox на Places. В репозитории существует более поздняя работа над миграцией картографического слоя, но открытая ветка разработки не должна выдаваться за функцию стабильного 2.4.0. Для эксплуатационной документации правильной опорой остаются настройки той версии и ветки, которую администратор реально запускает.

Публичные ссылки и загрузка

PhotoView создаёт публичные ссылки для отдельной фотографии, видео или целого альбома. В карточке файла раздел Sharing options сначала показывает отсутствие ссылок; команда Add shares создаёт Public link. Рядом находятся копирование ссылки, удаление и меню дополнительных действий. Ссылку разрешено защитить паролем, после чего получатель сначала видит форму ввода пароля.

У общего доступа есть важное ограничение: поле срока действия присутствует в описанном интерфейсе, но автоматическое истечение ссылки документировано как ещё не реализованная функция. Поэтому нельзя строить политику доступа на предположении, что ссылка сама отключится в заданную дату. Для закрытия доступа нужно удалить share либо применить внешний уровень контроля.

Чтобы ссылка работала вне домашней сети, сам PhotoView должен быть доступен извне. Проект не превращает локальный сервер в облачный endpoint автоматически. Администратор отвечает за DNS, обратный прокси, TLS и сетевую защиту. Это место, где удобство «одной ссылки для родственника» напрямую пересекается с безопасностью: публикация порта без нормальной защиты не равна корректно настроенному внешнему доступу.

Пользователи и разграничение библиотек

В PhotoView пользователь связан с файловыми путями. Администратор создаёт учётную запись, назначает ей Photo path и пароль. Флаг Admin открывает административные функции, включая ручной запуск сканирования и управление пользователями. Один пользователь может видеть несколько независимых корней, что полезно, когда личные фотографии, семейный архив и общая коллекция лежат на разных томах.

Разделение не требует физически дублировать общую папку. Два пользователя могут иметь пересекающийся путь, а сканер переиспользует обработанное медиа. При этом избранное и shares не становятся общими автоматически. Такая деталь важна для сценария «одна медиатека — разные аккаунты»: производные файлы не множатся без необходимости, но пользовательские действия остаются раздельными.

После создания нового пользователя документация рекомендует отдельно установить пароль через Change password. Нельзя считать пустую учётную запись готовой только потому, что путь уже виден в Settings. При проверке доступа следует войти именно под новым пользователем и убедиться, что он видит только назначенные корни и не получил Admin без необходимости.

Интеграции: Samba, FTP, Nextcloud и внешние хранилища

Связь PhotoView с Samba, FTP или Nextcloud не означает наличие отдельного коннектора к каждому сервису. Принцип проще: внешний инструмент организует или синхронизирует файлы, а PhotoView получает обычный файловый путь. Если Nextcloud хранит медиатеку на диске сервера и этот каталог корректно предоставлен контейнеру, PhotoView индексирует его как любую другую папку. То же относится к файлам, попадающим на сервер через Samba или FTP.

Такой подход снижает зависимость от API стороннего продукта и оставляет структуру переносимой: при удалении PhotoView папки не перестают быть организованными. Одновременно он переносит ответственность за консистентность на слой файловой системы. Если внешняя синхронизация ещё пишет большой файл в момент сканирования, если сетевой mount временно недоступен или если права изменились, сканер увидит именно состояние файловой системы в этот момент.

PhotoView не следует путать с сервисом резервного копирования смартфона. Для автоматической доставки новых фотографий с телефона до NAS нужен отдельный механизм синхронизации или загрузки. PhotoView вступает в работу после того, как файлы стали доступны на сервере. Это разделение часто удобно: один инструмент отвечает за передачу и сохранность, другой — за индекс и просмотр. Но пользователю, ожидающему «установить одно приложение на телефон и всё автоматически отправится в галерею», такой дизайн добавляет отдельный компонент.

Производительность и масштабирование

Производительность PhotoView строится вокруг предварительной обработки. Сканер создаёт небольшие миниатюры для сеток и, когда оригинал браузеру не подходит, более крупную JPEG-производную. В интерфейсе используется ленивое появление изображений: медиа загружаются по мере попадания в видимую область, а полноэкранный режим сначала показывает превью, пока не готово высокое разрешение. Это снижает стартовый объём передачи по сравнению с последовательной выдачей всех оригиналов.

Самая тяжёлая стадия — первичный или большой повторный скан. На ней одновременно работают чтение метаданных, декодирование изображений, генерация миниатюр, RAW-конвертация, видеопреобразование и распознавание лиц. Настройка concurrent workers управляет пиковым параллелизмом. На слабом сервере значение 1 уменьшает потребление ресурсов ценой времени. FAQ связывает случайные остановки сканера и строки signal: killed с нехваткой ресурсов и рекомендует уменьшить число воркеров.

База тоже влияет на масштаб. SQLite проще всего, но проект прямо ставит его на нижнюю ступень по производительности и масштабируемости. MariaDB LTS — компромиссный default. PostgreSQL позиционируется как обычно наиболее производительный вариант. Это не превращается в универсальную формулу «PostgreSQL всегда быстрее на любом NAS»: реальный результат зависит от дисков, объёма медиатеки, числа одновременных операций и конфигурации. Однако выбор СУБД — документированный рычаг, а не косметическая настройка.

Для видео доступно аппаратное ускорение FFmpeg через PHOTOVIEW_VIDEO_HARDWARE_ACCELERATION. Поддерживаются значения qsv, vaapi и nvenc. QSV проверен проектом на Intel: контейнеру передаётся /dev/dri. VAAPI также требует отображения /dev/dri. NVENC требует NVIDIA Container Toolkit, NVIDIA runtime и доступ к устройствам. Эта функция ускоряет совместимые стадии видеопайплайна, но не заменяет CPU, RAM и быстрый диск для остального сканирования.

Релиз 2.4.0 содержит несколько точечных улучшений производительности: переставлены аргументы FFmpeg для более быстрой генерации видеоминиатюр, ускорен старт воспроизведения видео, сканер перестал останавливать обработку всего альбома из-за ошибки отдельного медиа, а SQLite получил возможность нескольких одновременных соединений. Эти изменения полезно учитывать при сравнении 2.4.0 со старыми отзывами о ветке 2.3.x.

Кэш нужно планировать как постоянную часть установки. FAQ предупреждает, что его размер масштабируется вместе с библиотекой и способен стать очень большим. Удалённый кэш будет создан заново, поэтому стирать его на активно используемом сервере без причины означает заново оплачивать временем и ресурсами генерацию производных. При окончательном удалении PhotoView кэш и базу, напротив, можно убрать, поскольку оригиналы остаются в исходных каталогах.

Системные требования

Для PhotoView не опубликована универсальная минимальная конфигурация вида «2 GB RAM и двухъядерный CPU». Это важно не заменять вымышленным числом. Текущие требования сформулированы через поддерживаемые платформы и эксплуатационные компоненты. Основной путь — Docker с достаточно свежим Docker Engine и Compose; также перечислены поддерживаемые Linux и готовые платформенные интеграции.

Размер контейнера не равен требованию к свободному диску. Для 2.4.0 сжатый linux/amd64-образ занимает 527,3 MB, arm64 — 495,88 MB, но после распаковки Docker расход увеличивается, а затем к нему добавляются кэш, база, логи и резервные копии. На большой RAW/видеотеке именно производные медиа, а не размер самого образа, становятся заметной частью хранилища.

Для ручной сборки текущая ветка требует Go не ниже 1.22, g++, libheif не ниже 1.15.1, dlib, libjpeg, BLAS, LAPACK, libmagic, libmagickwand и Node 18 для UI. Эти пакеты относятся к сборке и локальной разработке, а не к хосту, который просто запускает готовый Docker-образ. Старые страницы manual setup содержат исторические примеры с более ранними версиями Go; их нельзя использовать как актуальный паспорт текущей ветки.

Безопасность и приватность

Сильная сторона архитектуры — возможность смонтировать исходную медиатеку в режиме чтения. PhotoView хранит производные отдельно и не требует переписывать оригиналы для обычного просмотра. Документация также указывает защиту медиаресурсов cookie-token, хеширование паролей и строгую CORS-политику API. Это уменьшает поверхность случайной порчи оригиналов и отделяет пользовательский интерфейс от файловой организации.

Однако встроенная аутентификация не превращает PhotoView в полностью подготовленный к открытому Интернету сервис. Текущая инструкция прямо рекомендует усилить защиту до внешней публикации. В числе подходов перечислены firewall, VPN, reverse proxy с HTTPS, внешний MFA, WAF, rate limiting, IDS/IPS и другие сетевые меры. Конкретная комбинация зависит от домашней сети и модели угроз, поэтому проект не обещает универсальную «безопасную галочку» внутри интерфейса.

Практически разумная граница выглядит так: медиатека монтируется read-only; база и кэш получают только необходимые права записи; наружу не публикуется внутренний порт без TLS и фильтрации; администратор использует отдельную сильную учётную запись; резервные копии базы и конфигурации хранятся отдельно от основного контейнера. Публичные shares следует считать реальными точками доступа: пароль повышает защиту, но не отменяет необходимость безопасного внешнего endpoint.

При работе с лицами и геотегами PhotoView хранит чувствительные производные сведения у владельца сервера, а не отправляет медиатеку в обязательное облако. Это даёт контроль, но одновременно делает администратора ответственным за сервер: резервное копирование базы, доступ к диску, TLS, обновления и журналирование. Self-hosted-модель меняет владельца риска, а не устраняет риск.

Практические сценарии использования

Семейный архив на NAS

Если семейные папки уже существуют, PhotoView добавляет к ним браузерное представление без миграции. Для каждого родственника можно назначить свой корень, общие каталоги пересечь, а отдельный альбом передать ссылкой с паролем. Главное ограничение — PhotoView не заменяет механизм загрузки новых фотографий с телефонов. Для доставки файлов на NAS нужен отдельный поток, после которого periodic scanner обновит галерею.

Архив фотографа с RAW+JPEG

Для пары RAW+JPEG программа способна избежать двойного представления, используя существующий JPEG как готовую визуальную версию. Darktable обрабатывает RAW, EXIF попадает в боковую панель, а исходный каталог остаётся основой. Такой сценарий особенно удобен, когда редактирование выполняется в другом ПО, а PhotoView нужен как read-only браузер и средство показать результат семье или клиенту.

Большая коллекция со слабым сервером

На ограниченном CPU первичный скан стоит запускать с меньшим числом concurrent workers, вплоть до 1. Это увеличивает длительность, но уменьшает риск OOM и завершения дочерних процессов сигналом. Для большой базы SQLite не является оптимальным масштабируемым выбором по собственной документации проекта; MariaDB или PostgreSQL требуют больше администрирования, зато рассчитаны на более серьёзную нагрузку.

Удалённый просмотр через Интернет

Внешний доступ следует строить через защищённый endpoint. PhotoView предоставляет аккаунты и shares, но сеть, HTTPS и дополнительные уровни контроля настраивает владелец. Для семьи, которой нужен только просмотр, парольная ссылка на конкретный альбом проще отдельной учётной записи. Для постоянного личного доступа полезнее полноценная авторизация через защищённый reverse proxy или VPN.

Мобильный сценарий

Старое официальное приложение iOS больше не поддерживается и недоступно в App Store. Поэтому PhotoView не стоит выбирать ради обещания современного фирменного мобильного клиента. Веб-интерфейс остаётся способом просмотра с телефона, а автоматический бэкап камеры и загрузка новых снимков требуют другого инструмента. Если мобильная загрузка является главным требованием, этот архитектурный компромисс нужно оценить до развёртывания.

Архив сканов без метаданных

Старые сканы хорошо подходят для папочной организации и просмотра, но автоматические Timeline и Places зависят от корректных дат и GPS. Если скан хранит только дату файла без качественного EXIF, PhotoView не превращает его автоматически в исторически точный снимок. Метаданные лучше нормализовать внешним инструментом, затем запустить пересканирование и проверить порядок на Timeline.

Плюсы и минусы PhotoView

Плюсы

• Сохраняет файловую систему главным источником организации и не требует перескладывать уже подготовленный архив.
• Позволяет монтировать медиатеку только на чтение, а миниатюры и производные хранит в отдельном кэше.
• Папки автоматически превращаются в Albums, а даты — в Timeline без ручного создания виртуальных альбомов.
• Поддерживает RAW через Darktable, EXIF и видео через FFmpeg; в 2.4.0 отдельно добавлен CR3.
• Есть People с ручным исправлением кластеров лиц и Places для реальных GPS-координат.
• Многопользовательская модель привязывает аккаунты к файловым путям и допускает пересечение библиотек без дублирования кэша.
• Общий доступ создаётся для отдельных медиа и альбомов, а ссылка допускает парольную защиту.
• Тонкая настройка нагрузки доступна через concurrent workers, а видео умеет использовать QSV, VAAPI и NVENC.
• Готовые контейнеры 2.4.0 опубликованы для amd64 и arm64.
• Проект открыт под AGPL-3.0; текущая ветка разработки остаётся активной после релиза 2.4.0.

Минусы

• PhotoView — прежде всего галерея над файловой системой, а не полноценный менеджер оригиналов; перемещение, переименование и организация файлов остаются внешнему инструменту.
• Нет поддерживаемого официального iOS-приложения: прежний клиент снят с поддержки и недоступен в App Store.
• Нумерованный релиз 2.4.0 опубликован в 2024 году, тогда как дальнейшая работа идёт в master; стабильный release cadence заметно отстаёт от коммитов.
• Публичная ссылка не имеет работающего автоматического срока истечения, хотя поле срока описано в интерфейсе sharing.
• Первичное сканирование RAW, видео и лиц способно быть ресурсоёмким; кэш растёт вместе с медиатекой.
• SQLite проще всего, но официально описан как самый слабый вариант по производительности и масштабированию.
• Для безопасной публикации в Интернет нужны внешний reverse proxy/VPN, TLS и другие меры; одной встроенной авторизации недостаточно для враждебной сети.
• Мобильный бэкап камеры, загрузка и синхронизация файлов не являются центральной функцией PhotoView и требуют отдельного решения.
• Поддержка кастомных платформенных схем ограничена; проблемы через Portainer предлагают сначала воспроизводить на обычном Docker Compose.

Типичные ошибки и способы проверки результата

Логи при Docker-развёртывании — первый технический источник диагностики самой установки. Старый FAQ приводит docker-compose logs; в современных Compose-окружениях применяется соответствующая команда Docker Compose для того же сервиса. Важно не ограничиваться сообщением веб-интерфейса: сбой Darktable, FFmpeg, базы или прав обычно виден на серверной стороне точнее.

Проверка после исправления должна быть узкой. После прав на каталог достаточно пересканировать один проблемный корень и убедиться, что новые файлы появились. После настройки ExifTool открыть конкретный файл с известными метаданными. После изменения worker count дождаться прохождения того участка, где раньше появлялся signal: killed. Такой контроль отделяет реальное исправление от случайного успешного открытия страницы.

Отзывы пользователей и профильных изданий

Что отмечали профильные публикации

В техническом обзоре Rair Dev 2021 года PhotoView прошёл не только по демо, но и через отдельную установку. Автор положительно оценил тогдашний Docker Compose, визуальную полировку интерфейса и разумные настройки по умолчанию; одновременно отметил небольшое пространство для кастомизации и неполную документацию того периода. Этот отзыв полезен как исторический срез ранней 2.3.x, но его нельзя переносить на нынешнюю документацию без поправки: после редизайна, 2.4.0 и дальнейших изменений master структура установки заметно менялась.

LinuxLinks описывал PhotoView как self-hosted фотогалерею с RAW/EXIF, видео, распознаванием лиц и ленивой загрузкой, указывая автора Viktor Strate Kløvedal и AGPL-3.0. Это скорее профильная карточка, чем нагрузочное тестирование, поэтому из неё уместно брать идентификацию и набор функций, но не делать вывод о скорости на конкретном NAS.

Актуальность экосистемы также видно по платформенным пакетам: в каталоге TrueNAS Community приложение продолжает обслуживаться, при этом upstream app version остаётся 2.4.0. Это показывает различие между обновлением упаковки для платформы и выпуском новой версии PhotoView: дата обновления каталога не превращает upstream 2.4.0 в новый релиз.

Что повторяется в пользовательских отзывах

Положительные отзывы обычно связаны с простотой интерфейса и уважением к существующим папкам. В обсуждениях self-hosted пользователи выбирали PhotoView именно потому, что не хотели, чтобы галерея перестраивала их архив, и ценили чистое представление, миниатюры и веб-конвертацию видео. Это совпадает с архитектурой программы и не требует рекламной интерпретации: сильная сторона проявляется там, где папки уже организованы.

Негативная тема — длительные сканы на очень больших библиотеках. В одном обсуждении 2022 года владелец примерно 800 GB и 600 тысяч фотографий сообщал о многочасовом сканировании даже после небольших добавлений, тогда как другой участник с около 100 GB видел обновление за минуты. В 2025 году другой пользователь после нескольких месяцев эксплуатации также жаловался на длительное обнаружение новых фото и видео. Эти сообщения нельзя превращать в норматив «PhotoView сканирует N часов»: они показывают сильную зависимость от объёма, железа, базы, типов файлов и конфигурации.

Ещё один повторяющийся компромисс касается больших оригиналов и медленного исходящего канала. Пользователь с крупными 20-мегабайтными сканами отмечал, что полноэкранный просмотр в старой версии переходил к оригиналу и становился тяжёлым на 10-мегабитном upload. В ответ обсуждалось, что PhotoView создаёт оптимизированные миниатюры, но полноэкранный режим ориентирован на высокое качество. Этот старый отзыв полезен для понимания модели, хотя конкретное поведение нужно проверять на текущем релизе и собственной сети.

Отдельные пользователи, которым требовалось удалять, переименовывать и переносить альбомы внутри веб-приложения, искали второй файловый менеджер или альтернативу. Это не случайный отсутствующий пункт меню, а следствие принципа «filesystem as source of truth». Для читателя главный вывод из отзывов не в том, что PhotoView «плохой менеджер», а в том, что выбирать его нужно как галерею поверх уже управляемого архива.

Сравнение с аналогами

PhotoView корректно сравнивать с другими self-hosted фотосистемами только по одинаковым задачам. Ни Piwigo, ни PhotoPrism не являются точной копией его модели. Piwigo сильнее ориентирован на управление галереей и загрузку, PhotoPrism предлагает и прямое индексирование originals, и отдельный import-процесс, а PhotoView делает файловую структуру центральным принципом и минимизирует вмешательство в оригиналы.

Для пользователя, который хочет сохранить каталоги буквально и монтировать их read-only, PhotoView остаётся самым прямым из трёх подходов. PhotoPrism тоже умеет индексировать originals без изменения файлов, поэтому он ближе к PhotoView, чем классический импортный менеджер, но предоставляет альтернативный import-процесс и более широкий набор библиотечных механизмов. Piwigo принципиально удобнее, когда фотографиями нужно активно управлять через сам веб-сервис и мобильные приложения.

На FreeEXE для соседних классов программ существуют отдельные страницы: фотоорганайзеры и каталогизация фотографий, фотогалереи, синхронизация и приватные медиатеки и карточка Piwigo. Эти ссылки помогают сравнить класс решений, но не меняют предмет этого обзора: PhotoView остаётся основной программой и оценивается по своей файловой модели.

FAQ по PhotoView

PhotoView копирует фотографии в собственную библиотеку?

Нет, его базовая модель строится на сканировании доступных каталогов. Оригиналы остаются там, где лежали, а PhotoView сохраняет в отдельном media cache миниатюры и производные. Поэтому папочную структуру можно продолжать обслуживать внешними средствами, а удаление самой галереи не разрушает организацию исходников.

Можно ли дать PhotoView только чтение к оригиналам?

Да. Архитектура специально рассчитана на read-only доступ к медиатеке, а запись нужна в кэш и базу. Это полезная граница прав: веб-сервис не обязан иметь возможность менять семейный архив только ради просмотра.

Почему папка хоста не видна в Initial Setup?

В Docker поле Photo path относится к файловой системе контейнера. Каталог хоста сначала монтируется volume, например в /photos, и именно контейнерный путь вводится в мастере. Если volume отсутствует, PhotoView не «угадает» каталог хоста.

Как добавить новые фотографии?

Скопируйте или синхронизируйте их в каталог, который уже назначен пользователю, затем запустите Scan либо дождитесь periodic scanner. Web-интерфейс PhotoView не является обязательной точкой импорта; доставка файлов на сервер выполняется отдельно.

Можно ли назначить пользователю несколько папок?

Да. Settings позволяет добавить несколько Photo path. Один путь того же пользователя не должен находиться внутри другого, а пути разных пользователей могут пересекаться.

Что произойдёт с общей папкой двух пользователей?

Общие медиа обрабатываются сканером один раз, чтобы не создавать повторный кэш. Избранное и публичные shares остаются индивидуальными для пользователей, поэтому общая физическая папка не превращает все пользовательские данные в общие.

Какая база подходит для небольшой домашней установки?

SQLite минимизирует число сервисов и обслуживание, поэтому удобен для простого инстанса. При этом проект прямо предупреждает о самой низкой производительности и отсутствии масштабируемости. Для растущей библиотеки MariaDB LTS названа стандартным компромиссом, PostgreSQL — более производительным, но более требовательным к сопровождению вариантом.

Нужен ли Darktable?

Для обычных браузерных изображений — нет. Darktable используется для RAW-конвертации. В ручной установке без него базовая галерея работает, но RAW processing недоступен; в контейнерном образе окружение подготавливается согласно образу проекта.

Нужен ли ExifTool?

В ручной установке ExifTool необязателен: PhotoView имеет внутренний EXIF-парсер. ExifTool используется для более быстрого и надёжного разбора метаданных. После его добавления стоит пересканировать несколько известных файлов и проверить боковую панель.

Поддерживает ли PhotoView видео?

Да. Распространённые видеоформаты проходят веб-оптимизацию через FFmpeg; MKV явно поддерживается с 2.3.5. Видеообработку разрешено отключить переменной окружения, при этом браузерно-совместимые ролики, не требующие перекодирования, остаются видимыми.

Зачем аппаратное ускорение видео?

Оно переносит совместимые операции FFmpeg на QSV, VAAPI или NVENC. Для QSV и VAAPI контейнеру передают /dev/dri; NVENC требует NVIDIA Container Toolkit и соответствующего runtime. Это снижает нагрузку на CPU именно на видеостадии, но не ускоряет автоматически EXIF, базу и распознавание лиц.

Можно ли выключить распознавание лиц?

Да. Переменная PHOTOVIEW_DISABLE_FACE_RECOGNITION полностью отключает функцию и скрывает People. Это полезно для слабого сервера, для коллекции без необходимости лицевой классификации или для более строгой модели приватности.

Почему карта пустая?

Places требует координаты в EXIF и корректную картографическую конфигурацию. Если у исходных файлов нет GPS, PhotoView не создаёт их автоматически. Для старых сканов геотеги нужно добавить внешним инструментом, затем выполнить повторное сканирование.

Можно ли поставить срок действия на share?

В документированном интерфейсе поле expiry присутствует, но сама функция автоматического окончания срока отмечена как не реализованная. Для гарантированного закрытия доступа share нужно удалить вручную или контролировать доступ внешним слоем.

Есть ли официальное приложение для iPhone?

Ранее оно существовало, но текущая страница PhotoView прямо сообщает, что официальный iOS-клиент больше не поддерживается и недоступен в App Store. Планировать новую установку вокруг старого приложения не следует.

Можно ли безопасно удалить media cache?

Кэш не содержит единственную копию оригиналов и способен быть создан заново, но при активной установке его удаление заставит PhotoView повторно генерировать миниатюры и производные. На большой библиотеке это дорого по времени и ресурсам. При полном удалении PhotoView кэш и базу можно удалить отдельно от исходников.

Почему master и 2.4.0 отличаются?

2.4.0 — последний нумерованный релиз, а master — развивающаяся ветка с автоматическими сборками. В master уже есть новые инфраструктурные требования, включая актуальную схему PostgreSQL 18 и новый Docker Registry. Использовать master следует осознанно, не называя его «PhotoView 2.5» без опубликованного релиза.

Итог: когда PhotoView оправдывает установку

PhotoView имеет чёткую специализацию: он превращает уже организованную файловую медиатеку в self-hosted веб-галерею, не захватывая управление оригиналами. Для NAS с аккуратными папками, RAW-архива фотографа или семейного сервера этот принцип даёт практическое преимущество — структура остаётся переносимой, а поверх неё появляются Timeline, Albums, EXIF, Places, People, избранное, веб-производные и shares.

Для небольшого личного сервера начинать разумно с релизного контейнера 2.4.0, read-only mount для оригиналов и понятной схемы базы/кэша. На слабом железе нужно сразу контролировать concurrent workers, а на большой коллекции — заранее выбрать СУБД и место под производные. Для внешнего доступа обязательным отдельным этапом становится сетевое усиление: HTTPS через reverse proxy или VPN, ограничение доступа и резервные копии.

Если главная задача — автоматический бэкап смартфона, активное перемещение файлов из веб-интерфейса, массовое редактирование библиотеки или современный нативный мобильный клиент, PhotoView не закрывает весь цикл одним приложением. В таком случае лучше либо дополнить его синхронизацией и файловым менеджером, либо выбрать систему, где загрузка и управление оригиналами являются центральными функциями. Если же файлы уже организованы и важнее сохранить эту организацию, архитектурная простота PhotoView остаётся его главным основанием для выбора.