PhotoView: фотоархив с альбомами, RAW, EXIF и картой

PhotoView превращает уже существующий фотоархив на сервере, NAS или домашнем хранилище в удобную веб-галерею: сканирует заданные папки, сохраняет их структуру как альбомы, строит временную ленту, извлекает EXIF, показывает RAW и видео, группирует лица и отмечает снимки на карте по GPS. Программа особенно полезна тем, кто привык самостоятельно раскладывать оригиналы по каталогам и хочет просматривать их с компьютера, планшета или телефона, не передавая библиотеку облачному сервису и не меняя привычную файловую организацию.

Как устроен PhotoView и что он делает с фотоархивом

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

Другие инструменты: ФотоМАСТЕР.

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

Веб-интерфейс разделён на несколько основных разделов. Timeline собирает медиатеку по времени съёмки, Albums повторяет дерево папок, Places отображает геотегированные фотографии на карте, People показывает найденные группы лиц, а Settings отвечает за пользователей, пути к библиотекам и параметры сканера. Внутри карточки фотографии доступна информационная боковая панель: там находятся метаданные, сведения о расположении файла в альбоме, связанные лица и место съёмки, варианты загрузки и управление публичными ссылками.

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

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

Установка и начало работы

Что подготовить до запуска

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

Медиакаталог лучше подключать к контейнеру в режиме только для чтения. Внутри контейнера путь может отличаться от пути на хосте: например, каталог NAS /volume1/photos монтируется как /photos. Именно внутренний путь вводится в мастере первоначальной настройки и затем в параметрах пользователей. Ошибка на этом шаге — одна из самых частых причин пустой библиотеки: в браузере администратор указывает путь хоста, а контейнер такого каталога не знает.

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

Современная конфигурация проекта предусматривает SQLite, MariaDB и PostgreSQL. SQLite проще для небольшой домашней инсталляции, потому что не требует отдельного серверного процесса, но документация прямо характеризует его как вариант с минимальной производительностью и без нормального масштабирования. MariaDB — компромисс по сложности и скорости. PostgreSQL предпочтительнее для более крупных инсталляций, но требует внимательнее относиться к версиям и миграциям. В актуальном шаблоне проекта для будущих сборок менялся путь тома PostgreSQL 18, поэтому нельзя механически переносить старый compose-файл на новую ветку: сначала сравнивают собственный конфиг с текущим примером и делают резервную копию базы.

Первый вход и путь к медиатеке

После запуска сервера браузер открывает страницу первоначальной настройки. Здесь создаётся первый администратор: задаются имя пользователя, пароль и путь к фотографиям внутри контейнера. Стандартный пример в документации использует /photos. Если каталог смонтирован иначе, вводят свой путь, а не путь из примера.

После создания учётной записи пустой интерфейс не означает, что файлы потеряны. Индекс ещё нужно построить. Администратор открывает Settings и запускает Scan All. Сканер проходит по разрешённым каталогам, определяет типы медиа, извлекает метаданные и формирует необходимые превью. На большой коллекции этот этап может занять значительное время и заметно нагрузить процессор, особенно если включены распознавание лиц, обработка RAW и перекодирование видео. PhotoView не обещает универсального времени сканирования: оно зависит от количества файлов, разрешения, кодеков, скорости дисков, базы и доступного CPU.

Если после Scan All ничего не появляется, проверку начинают не с переустановки, а с доступа к файлам. Внутри контейнера нужно убедиться, что каталог существует и его содержимое действительно видно процессу PhotoView. В официальном Docker-сценарии отдельно подчёркивается необходимость прав чтения и прохода по каталогам. Для дополнительных медиакорней те же права назначают каждому корню. На NAS также полезно проверить UID/GID, ACL и то, не запрещает ли контейнерной службе проход по одному из родительских каталогов.

Первое сканирование без перегрузки сервера

В разделе Settings есть параметр числа параллельных рабочих задач сканера. Чем их больше, тем больше файлов обрабатывается одновременно и тем выше пиковая нагрузка на процессор и память. На маломощном NAS или Raspberry Pi безопаснее начать с одного worker. Это снижает скорость первичной индексации, зато уменьшает риск, что система начнёт активно использовать swap или операционная система завершит процесс из-за нехватки памяти.

Если журнал показывает завершение задачи сигналом killed или сканирование обрывается при обработке тяжёлых RAW и видео, снижение числа concurrent workers до 1 — первый практический шаг. Затем проверяют свободную память, место в кэше, доступность Darktable и FFmpeg, права на исходный каталог и состояние базы. Увеличивать параллелизм имеет смысл только после того, как библиотека стабильно индексируется.

После начальной индексации можно включить периодический сканер. Он с заданным интервалом проверяет пользовательские пути и подхватывает новые медиа. Это удобно, если фотографии копируются на NAS другим процессом — например, rsync, Syncthing, сетевой папкой или из каталога Nextcloud. PhotoView в таком сценарии остаётся слоем просмотра, а доставкой файлов занимается отдельный инструмент.

Timeline: хронологический просмотр библиотеки

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

В верхней части Timeline есть фильтр даты и переключатель Show only favorites. Фильтр помогает ограничить ленту выбранным периодом, а второй режим оставляет только отмеченные сердцем кадры. Избранное сохраняется для пользователя, поэтому оно подходит как лёгкая форма отбора: например, отметить семейные фотографии для показа на телевизоре, кадры для дальнейшей обработки или лучшие снимки из поездки, не меняя файловую структуру.

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

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

Дата в Timeline зависит от метаданных, извлечённых из файла. Неправильные часы камеры, потерянный EXIF или ошибочный UTC offset могут поместить снимок не в тот день. PhotoView умеет разбирать временные метки и в выпуске 2.4.0 улучшал обработку времени с UTC-Offset, но он не является массовым редактором даты съёмки. Если метаданные испорчены, корректнее исправить их внешним инструментом в исходнике и затем выполнить повторное сканирование.

Albums: папки сервера как готовая система альбомов

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

Внутри альбома доступна сортировка. Документация перечисляет варианты By Date shot, By Date imported, By Title и By Kind (photos or videos); направление меняется стрелкой. Это позволяет, например, поставить кадры по времени съёмки, если имена файлов пришли из нескольких камер, либо сгруппировать фотографии и видео по типу. Для строгой авторской последовательности, не связанной с датой или именем, проще подготовить порядок на уровне файловой системы или использовать специализированный DAM.

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

Механика «папка равна альбому» накладывает и ограничение. Виртуальная коллекция, объединяющая файлы из разных каталогов без их перемещения, не является базовой моделью PhotoView. Избранное и подборки по лицам дают дополнительные представления, но если требуется развитая система произвольных альбомов, тегов, рейтингов и связей между медиа, PhotoPrism или Immich предоставляют более широкий каталогизационный слой.

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

Просмотр фотографии и информационная панель

Щелчок по миниатюре открывает фотографию в крупном представлении. Информационная кнопка с символом ⓘ вызывает правую боковую панель. В ней собраны сведения, которые PhotoView получил при сканировании: дата съёмки, камера, параметры экспозиции, путь альбома, информация о людях и местоположении, варианты загрузки и управление публикацией.

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

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

PhotoView не редактирует EXIF в оригинале. Если нужно массово изменить авторские поля, геокоординаты, описание или дату, это выполняют до сканирования с помощью EXIF-редактора, RAW-конвертера или DAM. После изменения метаданных потребуется повторный проход сканера, чтобы база получила актуальные значения.

Форматы фотографий, RAW и связка RAW+JPEG

PhotoView рассчитан не только на обычные JPEG. Браузерно совместимые изображения показываются напрямую или через подготовленные миниатюры, а форматы, которые браузер не умеет отображать, обрабатываются на сервере. Для RAW используется Darktable: сервер извлекает пригодное для веб-просмотра представление и сохраняет производные данные в кэш, не меняя исходный файл.

Это значит, что поддержка конкретного RAW фактически зависит не только от PhotoView, но и от возможностей установленной версии Darktable и его зависимостей. В релизе PhotoView 2.4.0 отдельно добавлялась поддержка CR3, но для редкой или новой камеры всё равно разумно проверить несколько файлов до массовой миграции архива. Если конкретный формат не обрабатывается, в первую очередь смотрят журнал сканера и убеждаются, что RAW processing не отключён переменной окружения.

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

Есть три способа снизить нагрузку, если RAW в библиотеке не нужен. Первый — предоставить PhotoView путь только к экспортированным JPEG. Второй — сохранить RAW в соседнем дереве, которое не входит в пользовательский media path. Третий — отключить RAW processing через соответствующую переменную окружения. Последний вариант удобен, когда в каталоге смешаны форматы, но администратор сознательно не хочет тратить CPU и место кэша на проявление RAW.

Для архивов со сканами, TIFF, HEIF и другими форматами нельзя полагаться на общее утверждение «поддерживается всё». Практический подход — создать тестовый каталог с representative-набором файлов, дать его отдельному пользователю или временно подключить как дополнительный путь, запустить сканирование и проверить журнал. Это быстрее выявляет реальные ограничения текущего контейнера, чем попытка судить по расширению файла.

Видео: преобразование для браузера и аппаратное ускорение

Видео PhotoView индексирует вместе с фотографиями и при необходимости оптимизирует для веб-воспроизведения с помощью FFmpeg. Исходник остаётся на месте, а совместимая производная версия хранится отдельно. Такой подход удобен для архивов с камер и телефонов, где наряду с JPEG и RAW встречаются ролики в кодеках, которые конкретный браузер воспроизводит плохо.

Перекодирование — одна из самых тяжёлых операций. На сервере без аппаратного ускорения длинный ролик высокого разрешения может надолго занять процессор. Поэтому при первичном сканировании большого архива имеет смысл начать с небольшого числа scanner workers и следить за температурой, памятью и свободным местом. Важна не «скорость PhotoView» сама по себе, а вся цепочка: чтение исходника, декодирование, FFmpeg, запись кэша и пропускная способность диска.

Проект поддерживает параметр PHOTOVIEW_VIDEO_HARDWARE_ACCELERATION. Для него предусмотрены варианты qsv, vaapi и nvenc. QSV ориентирован на Intel Quick Sync, VAAPI использует соответствующий Linux-интерфейс ускорения, NVENC — видеокарты NVIDIA. Для QSV и VAAPI контейнеру обычно передают устройство /dev/dri; для NVENC на хосте требуется корректно установленный NVIDIA Container Toolkit и доступ контейнера к GPU.

Аппаратное ускорение следует включать только после успешного программного сценария. Если обычное кодирование работает, а после добавления GPU видео перестаёт обрабатываться, проблема почти всегда находится в драйвере, правах на устройство, наборе кодеков или контейнерной конфигурации. В таком случае временно возвращаются к CPU, проверяют FFmpeg внутри контейнера и только затем снова подключают ускоритель.

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

Places: карта по координатам из EXIF

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

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

Если координаты ошибочны, исправить их непосредственно в PhotoView нельзя. Например, камера получила устаревшую позицию, а фотографии оказались на другом континенте. Правильная последовательность: изменить EXIF исходника внешней программой, убедиться, что файл действительно содержит новые latitude/longitude, после чего повторно просканировать каталог. Это соответствует общей философии проекта: метаданные файла являются исходной информацией, а PhotoView создаёт представление над ними.

Для карт в стабильной конфигурации используется Mapbox, поэтому администратору требуется токен через MAPBOX_TOKEN. Если токен отсутствует, неверен или ограничен неподходящими правилами, раздел Places может не работать как ожидается даже при наличии GPS. В такой ситуации сначала проверяют токен и сетевой доступ сервера/браузера к картографическим ресурсам, а уже затем пытаются пересканировать EXIF.

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

People: автоматическое обнаружение лиц и ручная разметка

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

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

Распознавание не следует воспринимать как безошибочную идентификацию личности. Контраст, поворот головы, возраст, освещение, очки, малая площадь лица и качество исходника влияют на группировку. Практически разумно сначала позволить системе обработать архив, затем подписать очевидные крупные группы и только после этого заниматься редкими ошибочными совпадениями.

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

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

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

PhotoView поддерживает несколько пользователей. Каждому назначается один или несколько путей к медиа. Пользователь видит фотографии только в доступных ему деревьях, а администратор может добавлять и редактировать учётные записи через Settings.

Для создания учётной записи используется New user. Сначала задаются имя и media path, затем для пользователя устанавливают пароль через Change password. Кнопка Edit открывает свойства существующей записи: там можно изменить пути и административные права. Флаг Admin даёт возможность управлять пользователями и вручную запускать сканирование.

Один пользователь может иметь несколько медиакорней. Это удобно, если часть фотографий лежит на быстром SSD, а старый архив — на большом HDD или сетевом томе. Однако все указанные каталоги должны быть доступны процессу PhotoView внутри его окружения. Для Docker это означает отдельное монтирование каждого корня, а не только наличие пути на хостовой системе.

Внутри одной учётной записи нельзя задавать пути, где один media path вложен в другой. Иначе один и тот же файл попал бы в область сканирования дважды. Разным пользователям пересекающиеся пути разрешены: сервер обрабатывает медиа один раз и не обязан дублировать кэш, но пользовательские избранные и публичные ссылки остаются независимыми.

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

Сканер: периодические проверки, исключения и контроль нагрузки

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

Periodic Scanner позволяет автоматически запускать повторную проверку через заданный интервал. Это практично при внешнем импорте. Например, телефон выгружает фотографии в Nextcloud, Nextcloud хранит файлы в собственном дереве, а PhotoView получает read-only mount к соответствующему каталогу пользователя. Новые файлы появляются без ручной загрузки в галерею, а периодический сканер превращает их в новые элементы медиатеки.

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

Игнорирование лучше продумать до первого полного сканирования. Если сначала проиндексировать миллион вспомогательных превью, а потом добавить правило, сервер уже потратит время и место. При изменении .photoviewignore нужен повторный проход, чтобы база синхронизировалась с новым набором файлов.

Число concurrent workers влияет не только на скорость, но и на устойчивость. Один worker последовательно обрабатывает элементы и наиболее предсказуем на ограниченной памяти. Несколько workers выгодны на многоядерном сервере с быстрыми дисками, но одновременно могут запустить несколько тяжёлых операций Darktable, FFmpeg и анализа лиц. Оптимальное значение определяется не абстрактной рекомендацией, а реальной нагрузкой конкретной коллекции.

Публичные ссылки и передача альбомов

PhotoView умеет публиковать отдельную фотографию или целый альбом по ссылке. Для одиночного медиа сначала открывают информационную панель, затем раздел Sharing options и кнопку + Add shares. Сгенерированную ссылку можно скопировать, удалить или открыть дополнительные параметры. Для альбома управление публикацией доступно через значок шестерёнки рядом с названием.

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

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

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

Безопасность: что нужно сделать до публикации сервера в интернете

PhotoView хранит личные фотографии, поэтому относиться к нему как к «обычной домашней страничке» нельзя. Официальная документация рекомендует не полагаться только на встроенную авторизацию, если сервер доступен из интернета. Практическая схема включает HTTPS, обратный прокси, актуальные контейнеры и зависимости, ограничение сетевого доступа, а при возможности — VPN, внешний MFA, rate limiting или дополнительный шлюз аутентификации.

Медиакаталоги разумно монтировать read-only. Тогда компрометация веб-приложения не даёт процессу простой возможности перезаписать оригиналы. Это не отменяет резервного копирования: read-only защищает от части сценариев изменения файлов через PhotoView, но не от отказа диска, ошибок администратора на хосте, ransomware в другой службе или повреждения файловой системы.

На момент подготовки материала особенно важна уязвимость CVE-2026-96271, опубликованная в сентябре 2026 года. Она затрагивает Photoview до версии 2.4.0 включительно и связана с проверкой прав в GraphQL-операции создания ссылки на альбом. Аутентифицированный пользователь может сформировать share для чужого альбома, зная или подбирая его идентификатор. Для многопользовательского сервера это не теоретическая мелочь: сгенерированная ссылка открывает опубликованные таким образом фотографии.

Исправление присутствует в более позднем коде репозитория, но отдельного стабильного релиза новее 2.4.0 на дату подготовки материала нет. Поэтому владелец многопользовательской инсталляции должен сознательно выбрать стратегию: ограничить доступ к непатченой 2.4.0 локальной сетью или VPN либо использовать код с исправлением, предварительно проверив актуальные compose-настройки и миграции. Простое выставление 2.4.0 напрямую в интернет без дополнительной защиты — плохая практика.

Обновление с ветки master требует большей дисциплины, чем установка релиза: конфигурационные примеры меняются, обновлялись имена образов, параметры базы и структура томов. Перед заменой контейнера сохраняют базу и конфигурацию, сравнивают собственный compose-файл с текущим примером и тестируют запуск на копии данных. Это особенно важно при переходе на PostgreSQL 18, где проект отдельно предупреждает об изменении точки монтирования каталога данных.

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

Оригиналы, кэш и резервное копирование

PhotoView не должен быть единственным местом хранения фотографий. В нормальной схеме оригиналы живут в независимом дереве, которое резервируется отдельным инструментом. PhotoView читает их и строит индекс. Поэтому отказ базы или потеря кэша не уничтожает исходные JPEG, RAW и видео; систему можно развернуть заново и пересканировать медиатеку.

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

Кэш занимает промежуточное положение. Его можно пересоздать из оригиналов, но на большом RAW/video-архиве это дорого по времени и вычислениям. Если объём резервного хранилища ограничен, кэш можно не включать в ежедневный бэкап, однако тогда восстановление будет сопровождаться длительным пересчётом превью. На малом сервере иногда дешевле хранить резервную копию кэша, чем повторно прогонять десятки тысяч файлов.

Перед обновлением PhotoView критичнее всего сохранить базу. Если одновременно обновляется СУБД, нужно иметь её собственный корректный дамп, а не только копию каталога контейнера. Для PostgreSQL и MariaDB штатные инструменты логического резервирования дают более переносимый результат, чем «горячее» копирование файлов работающей базы.

Nextcloud, Samba и другие внешние источники

PhotoView не требует, чтобы файлы были загружены именно через него. Это позволяет ставить его поверх существующей инфраструктуры. Например, каталог Nextcloud монтируется в контейнер PhotoView в режиме чтения, в настройках пользователя указывается соответствующий внутренний путь, после чего запускается сканирование. Новые файлы появляются после последующих проходов сканера.

При работе с Nextcloud нужно понимать его физическую структуру данных. PhotoView должен видеть реальные файлы, а не WebDAV-ссылку или абстрактное представление облака. На сервере указывают путь к каталогу файлов нужного пользователя и дают контейнеру права чтения. Любые изменения лучше выполнять через Nextcloud или файловую систему, а PhotoView оставлять потребителем.

То же относится к SMB/Samba и NFS. Если сетевой ресурс уже смонтирован на хосте, контейнеру передают этот mount как том. Надёжность PhotoView тогда зависит от доступности сетевой файловой системы: если NAS временно пропал, запускать массовое сканирование не стоит, чтобы временное отсутствие файлов не смешалось с реальным удалением. После восстановления монтирования проверяют несколько каталогов и только затем запускают обновление индекса.

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

Производительность без магических цифр

Нельзя назвать «нормальное» число фотографий в секунду, потому что разные этапы сканирования имеют разную стоимость. JPEG с готовым EXIF на NVMe обрабатывается иначе, чем 60-мегапиксельный RAW на медленном HDD. Видео добавляет FFmpeg, People — анализ лиц, карта — обработку геоданных, а база данных влияет на запись и выборку индекса. Поэтому производительность PhotoView оценивают по узкому месту конкретной системы.

Если интерфейс медленно открывает уже проиндексированные альбомы, смотрят на кэш, базу и сеть. Если тормозит только первичное сканирование, проверяют CPU, память, Darktable, FFmpeg и concurrent workers. Если задержки появляются только при полноразмерном просмотре, вероятнее проблема в скорости чтения оригиналов или канале до клиента. Разделение этих сценариев экономит время: нет смысла менять СУБД, если сервер упирается в декодирование RAW.

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

На мощном сервере чрезмерный параллелизм тоже может ухудшить ситуацию. Одновременная обработка многих RAW увеличивает память, несколько FFmpeg-процессов конкурируют за GPU/CPU, а база получает пиковую запись. Поэтому «все ядра заняты» не равно «индексация идёт оптимально». Следите за iowait, swap, очередью диска и ошибками контейнера, а не только за процентом CPU.

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

Типичные ошибки и способы устранения

В интерфейсе нет фотографий после Scan All

Сначала проверьте путь внутри контейнера. Если в настройках указано /volume1/photos, а контейнеру каталог смонтирован как /photos, PhotoView смотрит не туда. Второй шаг — права: процесс должен читать файлы и иметь право прохода по всем родительским каталогам. Третий — журнал сканера: он покажет ошибку открытия директории, неподдерживаемый файл или сбой внешнего обработчика.

Сканирование завершается сообщением signal: killed

Чаще всего это признак нехватки памяти или вмешательства OOM killer. Уменьшите Concurrent Workers до 1 и повторите проход. Если проблема исчезла, увеличивать значение нужно постепенно. Одновременно проверьте лимиты памяти контейнера и swap. Особенно тяжёлая комбинация — параллельные RAW, распознавание лиц и видео.

RAW отображается неправильно или не появляется

Убедитесь, что обработка RAW не отключена и Darktable присутствует в образе/окружении, которое реально запускает сервер. Затем протестируйте отдельный файл и посмотрите журнал. Новый формат камеры может требовать более свежей версии Darktable. Если рядом лежит JPEG с тем же базовым именем, PhotoView может использовать его как counterpart — это штатный сценарий, а не потеря RAW.

Видео есть в альбоме, но не воспроизводится

Проверьте, удалось ли FFmpeg создать совместимую веб-версию. Если включено аппаратное ускорение, временно отключите его: так можно отделить проблему исходного кодека от проблем драйвера или GPU. Для QSV/VAAPI проверьте доступ контейнера к /dev/dri; для NVENC — установку NVIDIA Container Toolkit.

Places пуст, хотя фотографии сняты телефоном

Откройте EXIF одного проблемного кадра и убедитесь, что там действительно есть GPS. Если координаты существуют, проверьте, включён ли раздел карт и задан ли рабочий Mapbox token. Если GPS отсутствует, пересканирование ничего не добавит — сначала нужно записать координаты во внешнем редакторе метаданных.

На карте фотография находится не там

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

Одно лицо разбито на несколько групп

Откройте People, выберите одну группу и воспользуйтесь Merge face, найдя нужного человека в списке. Если, наоборот, в группе оказался чужой кадр, используйте отделение или перемещение лиц. На больших группах операция может занимать заметное время.

Папка видна одному пользователю, но не другому

Проверьте media paths обеих учётных записей. Доступ определяется назначенными корнями, а не фактом физического наличия каталога на сервере. Если добавлен новый путь, контейнер также должен иметь соответствующий mount. После изменения выполните сканирование.

После обновления база не запускается

Не начинайте с удаления тома. Сначала верните предыдущие контейнеры и восстановите конфигурацию из копии. Затем сравните свой compose-файл с текущим примером проекта. При PostgreSQL особенно проверьте версию и точку монтирования данных: переход к версии 18 сопровождался изменением рекомендуемого пути тома. Любое обновление СУБД выполняют только с проверенной резервной копией.

Публичная ссылка должна перестать работать в заданный день

Не рассчитывайте на автоматический срок действия, если его нет в вашей установленной сборке. Создайте share, защитите паролем при необходимости и запланируйте ручное удаление после передачи. Для строго регламентированного доступа используйте внешний reverse proxy или систему, где expiration является подтверждённой функцией.

Практический сценарий: фотоархив на NAS

Допустим, на NAS уже есть дерево /photos/2024, /photos/2025, /photos/2026, а внутри — поездки и события. Создавать вторую структуру в веб-приложении не нужно. Подключите корень к контейнеру как /photos:ro, выделите отдельный том под кэш и базу, запустите PhotoView и укажите /photos первому пользователю.

На первом проходе оставьте один scanner worker, особенно если архив содержит RAW и видео. После нескольких сотен файлов проверьте Timeline, Albums, EXIF, карту и People. Если всё корректно, разрешите сканеру закончить библиотеку. Лишь после этого увеличивайте параллелизм, потому что раннее ускорение усложняет диагностику.

Если супругам или членам семьи нужны разные приватные области, физически разделите каталоги и создайте отдельные учётные записи с соответствующими media paths. Общую папку можно сделать доступной обоим через пересекающиеся корни разных пользователей. Избранное и share-настройки при этом остаются пользовательскими.

Для поступления новых снимков используйте привычный канал — например, Syncthing или Nextcloud. PhotoView не нужно превращать в загрузчик. Включите Periodic Scanner с разумным интервалом, чтобы новые файлы появлялись автоматически. Такое разделение обязанностей упрощает резервирование: транспорт отвечает за доставку, файловая система — за структуру, PhotoView — за просмотр.

Практический сценарий: архив фотографа с RAW и JPEG

У фотографа часто есть три слоя: RAW-оригиналы, отобранные JPEG и клиентские экспорты. Если дать PhotoView корень целиком, в интерфейсе окажутся и рабочие, и финальные файлы. Обычно удобнее решить на уровне каталогов, что должно быть доступно в галерее. Например, raw и jpeg можно хранить рядом для использования counterpart-механизма, а технические превью и временные экспорты исключить через .photoviewignore.

Клиентские альбомы логично размещать в отдельных подкаталогах с понятными именами. Тогда они автоматически появятся как Albums и могут быть опубликованы по ссылке. Если клиенту нужен пароль, его задают в Sharing options. После завершения проекта ссылку удаляют вручную.

PhotoView не заменяет RAW-конвертер. Цветокоррекция, профили камеры, локальные маски, ретушь и экспорт выполняются в специализированном редакторе. Зато PhotoView удобен как «витрина» уже подготовленного архива: с EXIF, быстрыми миниатюрами, картой, лицами и доступом с разных устройств.

Практический сценарий: семейная медиатека с телефонами

Телефоны дают PhotoView особенно полезные метаданные: дату, модель камеры и часто GPS. Если файлы автоматически попадают на домашний сервер, Timeline начинает работать как общая хронология, Places — как карта поездок, а People — как поиск по членам семьи.

При этом PhotoView сам не является полноценной системой резервного копирования смартфона. Для автоматической доставки снимков нужен отдельный инструмент. В сравнении с Immich это принципиальная разница: Immich имеет мобильные приложения с автоматическим backup и умеет создавать серверные альбомы по альбомам телефона, тогда как PhotoView ожидает, что файлы уже находятся в доступном каталоге.

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

Что PhotoView принципиально не заменяет

Первое — редактор изображений. Нельзя открыть портрет, удалить прыщ, заменить фон, выполнить пластику лица, построить кривую или применить 3D LUT и сохранить результат. Для этого нужен ФотоМАСТЕР, Photoshop-подобный редактор, RAW-конвертер или другой инструмент обработки.

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

Третье — развитый DAM с пользовательскими тегами и сложным поиском по содержимому. В PhotoView есть поиск и специализированные представления, но он не предлагает тот же уровень AI-классификации, комбинируемых фильтров и семантического поиска, который развивают PhotoPrism и Immich.

Четвёртое — редактор файловой структуры. Папки создаются, переименовываются и перемещаются за пределами PhotoView. Это сознательный дизайн, а не недостающая кнопка: программа берёт структуру с диска и отображает её как Albums.

Переменные окружения: что настраивать, а что не трогать без причины

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

PHOTOVIEW_DATABASE_DRIVER выбирает backend базы. В документации встречаются значения mysql, postgres и sqlite. В зависимости от драйвера задаётся одна из строк подключения: PHOTOVIEW_MYSQL_URL, PHOTOVIEW_POSTGRES_URL или путь PHOTOVIEW_SQLITE_PATH. Если драйвер и строка подключения не соответствуют друг другу, сервер не сможет корректно открыть базу; маскировать эту ошибку пересозданием контейнера бессмысленно.

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

Сетевые параметры PHOTOVIEW_LISTEN_IP и PHOTOVIEW_LISTEN_PORT определяют, где слушает серверная часть. PHOTOVIEW_SERVE_UI управляет раздачей статического интерфейса самим сервером, а при разделённом размещении UI и API используются соответствующие endpoint-параметры. Для типичной Docker-инсталляции лучше начинать с официального compose-примера, а не собирать сетевую схему из отдельных переменных: так меньше риск получить UI, который открывается, но обращается к неправильному API.

Три переменные позволяют полностью отключить тяжёлые подсистемы: PHOTOVIEW_DISABLE_FACE_RECOGNITION, PHOTOVIEW_DISABLE_VIDEO_ENCODING и PHOTOVIEW_DISABLE_RAW_PROCESSING. Это не «режим экономии качества», а сознательное исключение функций. Если отключить распознавание лиц, исчезает соответствующий раздел; при отключении видео-кодирования остаются только ролики, которые браузер способен воспроизвести без серверного преобразования; без RAW processing сервер не создаёт JPEG-представления RAW.

MAPBOX_TOKEN относится только к картографической части. Не следует добавлять токен «на всякий случай», если Places не используется. Если карта нужна, ограничьте токен по допустимому домену там, где это поддерживается, и не публикуйте секреты вместе с compose-файлом. В рабочей конфигурации секреты лучше хранить в отдельном env-файле с ограниченными правами.

Как выбрать базу данных для конкретного архива

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

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

Критическая ошибка — выбирать базу только по таблице «быстрее/медленнее», а затем не иметь процедуры резервирования. Для PhotoView полезнее стабильная MariaDB с ежедневным дампом и понятным восстановлением, чем формально более производительный PostgreSQL без проверенного бэкапа. То же верно и наоборот: если в инфраструктуре уже есть PostgreSQL, держать отдельную SQLite только ради кажущейся простоты не обязательно.

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

Отдельно учитывайте изменения версии PostgreSQL. В актуальной ветке проекта переход к PostgreSQL 18 сопровождается изменением точки монтирования каталога данных внутри контейнера. Если старый volume привязан к пути, который соответствовал PostgreSQL 17, механическая замена номера образа может привести к тому, что новая СУБД увидит пустой каталог или откажется запускаться. Перед таким обновлением делают логический дамп, читают текущий пример compose и только затем меняют сервис.

Файловая структура как часть интерфейса

В PhotoView удачная структура каталогов одновременно является и навигацией. Если на диске лежат папки 2019, 2020, 2021 и внутри десятки событий с понятными именами, Albums будет читаемым без дополнительной настройки. Если же корень заполнен каталогами DCIM_1, OLD, new_new и техническими экспортами, веб-интерфейс честно повторит этот хаос.

Поэтому перед подключением старого архива имеет смысл провести файловую ревизию вне PhotoView. Не обязательно переименовывать всё: достаточно отделить постоянные оригиналы от временных папок, кэшей других программ и резервных дублей. Затем технические каталоги исключают с помощью .photoviewignore или вообще не включают в media path.

Хорошая схема имён должна быть понятна без базы PhotoView. Например, дата и событие в названии каталога помогают и в файловом менеджере, и в Albums. Это полезно при восстановлении: даже если база временно недоступна, архив остаётся структурированным. В этом и состоит практический смысл принципа filesystem as source of truth — порядок не заперт внутри одной программы.

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

Переименование каталогов лучше выполнять пакетно и затем запускать сканирование. Не стоит перемещать десятки тысяч файлов во время активного scanner-прохода: временно исчезающие пути усложняют диагностику. После большой реорганизации полезно открыть несколько уровней Albums, проверить пути в информационной панели и убедиться, что старые элементы исчезли, а новые появились там, где ожидалось.

.photoviewignore на практике

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

Типичный пример — каталог проекта фотографа, где рядом с оригиналами лежат cache, preview, временные экспорты и служебные папки редактора. Если их индексировать, Timeline засоряется техническими изображениями, а сервер зря создаёт миниатюры. Гораздо дешевле исключить их до первого полного прохода.

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

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

Не используйте ignore-файл для разграничения пользователей. Это глобальная логика сканирования каталога, а права пользователей задаются media paths. Если семейный альбом должен видеть один человек и не видеть другой, правильнее разделить корни доступа, а не пытаться скрыть папку шаблоном.

Метаданные: что PhotoView читает и почему исходник важнее базы

PhotoView извлекает EXIF, чтобы показать технические параметры, построить хронологию и карту. Это делает качество встроенных метаданных частью пользовательского опыта. Один и тот же набор файлов с аккуратными датами и GPS выглядит как связная история; архив после многолетних экспортов без EXIF превращается в набор картинок, где Timeline и Places дают меньше пользы.

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

GPS тоже лучше хранить в самом файле или стандартизованном sidecar, если используемый рабочий процесс это поддерживает. PhotoView не является геотеггером: он показывает координаты, но не предоставляет инструмент для ручного перетаскивания точки на карте с записью результата обратно. Поэтому операция «исправить место» выполняется внешним инструментом и завершается повторным сканированием.

Описание, модель камеры и экспозиционные параметры зависят от того, что реально присутствует в медиа. Если экспорт из редактора удалил metadata, PhotoView не сможет показать объектив или выдержку, даже если эти данные были в первоначальном RAW. Для публичных JPEG это иногда делается сознательно ради приватности. В таком случае отсутствие EXIF — нормальный результат политики экспорта, а не ошибка сканера.

В профессиональном рабочем процессе полезно выбрать одну точку, где метаданные считаются окончательными. Например: RAW-конвертер записывает корректные дату, авторство и GPS в JPEG; после этого JPEG поступает в архив; PhotoView только читает его. Такой порядок снижает конфликт между несколькими программами, каждая из которых могла бы хранить собственную версию описаний.

Как диагностировать проблемы по слоям

PhotoView состоит не из одного процесса «покажи фотографию». Между файлом и браузером есть файловая система, scanner, внешние обработчики, кэш, база, API и веб-интерфейс. Быстрая диагностика начинается с определения слоя, на котором проявляется ошибка.

Если конкретного файла нет вообще, сначала проверяют файловую систему и scanner. Видит ли контейнер каталог? Не исключён ли файл через .photoviewignore? Есть ли ошибка при чтении формата? Если запись присутствует, но миниатюра пустая, смотрят обработчик изображения и каталог PHOTOVIEW_MEDIA_CACHE. Если миниатюры есть, но UI выдаёт ошибку при открытии, проверяют API, сеть и браузер.

Если проблема возникает только у одного пользователя, вероятнее всего она связана с media path или правами в базе, а не с декодером изображения. Если одна и та же фотография видна одному аккаунту и отсутствует у другого, нет смысла переустанавливать Darktable. Нужно сравнить корни пользователей и то, какие каталоги фактически входят в каждый путь.

Если нестабильность начинается во время тяжёлой индексации, смотрят ресурсы: память, CPU, iowait, место в кэше и журнал OOM. Если сервер стабилен после уменьшения workers, причина почти наверняка в конкуренции за ресурсы. Если проблема не зависит от параллелизма и повторяется на одном файле, исследуют именно этот формат или повреждение исходника.

Если интерфейс открывается через локальный адрес, но ломается через домен, scanner и база, скорее всего, ни при чём. Проверяют reverse proxy, заголовки, TLS, публичный endpoint и правила CORS. Разделение симптомов по слоям позволяет исправлять конфигурацию точечно, а не сбрасывать рабочую библиотеку.

Reverse proxy и удалённый доступ

В локальной сети PhotoView можно сначала проверить по прямому порту. Для постоянного внешнего доступа лучше поставить перед ним обратный прокси и использовать HTTPS. Прокси завершает TLS, перенаправляет запросы к контейнеру и может добавить ограничения, которых нет в самой галерее: rate limiting, дополнительную аутентификацию, фильтрацию по IP или интеграцию с VPN.

При такой схеме важно не публиковать служебные порты без необходимости. Внешнему пользователю нужен веб-интерфейс через один контролируемый вход, а база данных и внутренние сервисы должны оставаться в приватной сети Docker или на localhost. Открытая в интернет СУБД не помогает PhotoView и лишь расширяет поверхность атаки.

Если сервер доступен только семье, VPN часто проще и надёжнее публичного домена. Пользователь сначала подключается к домашней сети, а затем открывает PhotoView как локальный сервис. Такой подход особенно уместен, пока стабильный релиз 2.4.0 остаётся затронут уязвимостью shareAlbum: дополнительный сетевой периметр снижает доступность атакующей поверхности извне.

Если нужен публичный share для клиента, VPN не всегда подходит. Тогда лучше использовать отдельный домен через HTTPS и строго ограничивать опубликованные альбомы. Пароль на share защищает от случайного доступа по ссылке, но не заменяет исправление уязвимостей и обновление самого приложения.

После настройки прокси тестируют не только вход в учётную запись. Нужно открыть несколько миниатюр и оригиналов, скачать альбом, проверить share-ссылку в приватном окне и открыть API-зависимые разделы. Ошибка размера тела запроса или таймаута прокси может проявиться только на крупном файле, а неправильный базовый URL — только при конкретном переходе интерфейса.

Обновление без потери рабочей конфигурации

PhotoView обновляется не так, как обычная программа на одном ПК: вместе с приложением могут измениться контейнерный образ, схема базы, переменные окружения и пример compose. Поэтому перед обновлением фиксируют текущую версию, сохраняют compose и env, делают дамп БД и проверяют, что оригиналы действительно находятся вне контейнера.

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

После обновления сначала запускают сервер без массового сканирования и проверяют миграции базы. Затем входят в интерфейс, открывают несколько старых альбомов и только после этого запускают scanner. Такой порядок позволяет отличить проблему миграции от ошибки обработки медиа. Если всё делать одновременно, в журнале смешиваются сообщения базы, Darktable, FFmpeg и scanner.

В случае ветки master риск выше. В ней быстрее появляются исправления, включая важные security-fix, но конфигурация может опережать последний релиз. Использовать master разумно только тогда, когда администратор готов читать изменения и тестировать обновление. Для сервера с ценным архивом «самая свежая сборка» без бэкапа не является преимуществом.

Откат тоже следует планировать заранее. Если новая версия уже изменила схему БД, простой возврат старого контейнера может не запуститься. Поэтому резервная копия должна быть сделана до миграции. Возврат означает восстановление совместимого дампа, а не только смену тега образа.

Поведение на телефоне, планшете и слабом клиенте

Основная тяжёлая обработка PhotoView выполняется на сервере, поэтому клиенту не нужно уметь проявлять RAW или перекодировать видео. Браузер получает веб-представление и миниатюры. Это удобно для телефона и планшета: даже если оригинал весит десятки мегабайт, лента может сначала показать уменьшенную версию.

Однако слабый клиент всё равно влияет на удобство. Большая сетка, множество DOM-элементов и декодирование полноразмерных изображений потребляют память браузера. Если старый планшет начинает выгружать вкладку, не нужно увеличивать scanner workers — это серверный параметр. На клиенте помогает открывать меньшие подборки, использовать стабильный современный браузер и не держать одновременно множество вкладок с галереей.

У PhotoView существовали отдельные мобильные клиенты, но основной рабочий интерфейс остаётся веб-галереей. Поэтому при выборе системы для автоматического резервного копирования телефона важно не спутать «удобно смотреть с телефона» и «умеет автоматически выгружать медиатеку телефона». Для второго сценария у Immich есть полноценный мобильный backup, а с PhotoView нужен отдельный канал синхронизации.

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

Рабочий процесс с фоторедактором

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

Если нужен быстрый ретуширующий этап в Windows, ФотоМАСТЕР может применяться к выбранному JPEG или RAW: убрать объект, заменить фон, скорректировать портрет, цвет и тон. Сохранённый результат помещается в каталог, уже известный PhotoView. При следующем сканировании он появится в нужном Albums и Timeline. Это практичнее, чем ожидать от PhotoView инструментов, которых у него нет.

Главное — избегать циклического экспорта. Если редактор сохраняет новые JPEG в тот же каталог, а затем повторно импортирует их как новые исходники, быстро образуются дубли. Лучше заранее определить директории originals, exports и, при необходимости, client, а PhotoView дать только те корни, которые должны быть видны в галерее.

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

Когда кэш становится отдельной задачей

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

Поэтому место под PHOTOVIEW_MEDIA_CACHE планируют с запасом и контролируют по фактическому росту. Если кэш заполнит файловую систему, новые превью перестанут создаваться, а симптомы могут выглядеть как проблема scanner. Мониторинг свободного места на разделе кэша полезнее, чем попытка заранее угадать точный объём.

Хорошая схема на NAS — оригиналы на ёмком HDD-массиве, кэш и база на SSD. Веб-интерфейс чаще обращается именно к производным данным и базе, поэтому такая раскладка улучшает отзывчивость без переноса всего архива на дорогой флеш-накопитель. Полноразмерный оригинал всё равно читается с HDD при открытии или загрузке.

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

Права на файлы и read-only как практическая защита

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

Read-only не исправляет неверные UNIX-права. Если процесс не может читать файл или проходить по каталогу, флаг :ro лишь сохраняет запрет на запись; доступа на чтение он не добавляет. Нужно согласовать UID/GID контейнера, ACL и права родительских директорий. На Synology, TrueNAS и других NAS механизм может дополняться собственными ACL, поэтому проверку лучше делать изнутри контейнера.

Кэш, база и временные каталоги, напротив, должны быть записываемыми. Если по ошибке сделать read-only весь контейнер без необходимых writable mounts, сервер откроет интерфейс лишь частично либо начнёт сыпать ошибками при создании миниатюр. Разделение томов помогает точно назначать права.

Не запускайте контейнер с избыточными привилегиями только ради решения проблемы доступа. Если PhotoView требует root для чтения медиатеки, обычно это сигнал, что mount или ACL настроены неверно. Минимальные права проще аудировать и безопаснее при внешнем доступе.

Как проверить новую библиотеку до полного импорта

Перед тем как направить PhotoView на многотерабайтный архив, соберите небольшой тестовый каталог. В него стоит включить обычный JPEG, RAW от каждой важной камеры, пару видео разных кодеков, фотографию с GPS, портрет с несколькими лицами и снимок без EXIF. Такой набор быстро показывает, какие зависимости работают в конкретной сборке.

Подключите каталог отдельным media path и запустите сканирование с одним worker. Затем проверьте не только наличие миниатюр, но и каждый функциональный слой: Timeline, путь Albums, EXIF, Places, People, полноразмерное открытие, скачивание и public share. Если тест проходит, вероятность неприятного сюрприза на полной библиотеке заметно меньше.

Особенно полезна проверка RAW. Формат расширения сам по себе не гарантирует поддержку конкретной камеры. Один CR3 может обрабатываться, другой от более новой модели — требовать свежей версии Darktable. Тестовые файлы позволяют выяснить это до многочасового сканирования.

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

Настройки под разные типы сервера

На малом ARM-сервере или NAS с 2–4 ГБ памяти приоритетом должна быть предсказуемость. Начните с одного scanner worker, отключите анализ лиц, если он не нужен, и не включайте аппаратное ускорение видео до проверки обычного FFmpeg. SQLite допустим для небольшой персональной библиотеки, но если на том же NAS уже работает MariaDB, отдельный серверный backend может оказаться удобнее для резервирования и обслуживания.

На домашнем x86-сервере с несколькими пользователями имеет смысл вынести базу и кэш на SSD, а оригиналы оставить на HDD-массиве. После полного первичного сканирования можно постепенно поднять число workers и оценить, не растут ли iowait и память. Для большого числа роликов стоит проверить Quick Sync или VAAPI; для NVIDIA — NVENC. Ускорение выбирают по тому, что реально доступно хосту, а не по названию параметра.

На сервере, где PhotoView доступен извне, главным параметром становится не количество workers, а граница доверия. UI и API публикуют только через HTTPS-прокси, базу не выводят наружу, оригиналы монтируют read-only, а административный аккаунт защищают сильным уникальным паролем. Для семейного доступа предпочтителен VPN. При многопользовательской схеме дополнительно учитывают актуальные security advisory, потому что именно межпользовательская изоляция затрагивается CVE-2026-96271.

На архивном сервере без видео можно отключить video encoding. На сервере с готовыми JPEG-экспортами и RAW, которые нужны только как резерв, можно отключить RAW processing либо вовсе не включать каталог RAW в media path. Наоборот, если PhotoView используется как основной просмотрщик необработанных файлов, Darktable должен быть частью проверяемой конфигурации, а место кэша рассчитывают с большим запасом.

При нескольких пользователях не стремитесь сделать один огромный корень и затем «объяснить» права приложению. Проще физически отделить приватные деревья и назначить каждому понятные media paths. Общие каталоги можно подключать нескольким аккаунтам. Такая схема прозрачна при резервировании и легче проверяется внутри контейнера.

Что проверить перед тем, как дать доступ другим людям

Сначала войдите под обычной, не административной учётной записью. Убедитесь, что ей недоступны чужие корни и Settings с управлением пользователями. Откройте несколько альбомов из разных веток, проверьте пути в боковой панели и попытайтесь найти кадры, которые заведомо должны быть приватными. Эта проверка важнее красивой стартовой страницы.

Затем создайте тестовую public share на небольшой альбом. Откройте ссылку в приватном окне браузера, задайте пароль и убедитесь, что доступ ограничен именно выбранным содержимым. После теста удалите share и проверьте, что ссылка перестала работать. На версиях, затронутых CVE-2026-96271, такой функциональный тест не заменяет исправление: уязвимость находится в авторизации операции создания share, а не в обычном сценарии просмотра.

Проверьте скачивание. Пользователь должен понимать разницу между full resolution и уменьшенной копией. Если сервер имеет медленную исходящую линию, предупредите, что загрузка целого альбома в полном размере может быть долгой. Для разовой передачи большого проекта лучше подготовить отдельный архив вне PhotoView, чем заставлять веб-приложение собирать его под нагрузкой.

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

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

Контрольный сценарий восстановления

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

Сначала проверяются пользовательские данные, которые нельзя восстановить простым сканированием: избранное, подписи People, учётные записи и настройки. Затем открывают Albums и несколько медиа. Если кэш не резервировался, миниатюры могут отсутствовать до повторной обработки — это ожидаемо. Главное, чтобы оригиналы оставались доступны и база успешно связалась с ними.

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

Проверку стоит повторять после крупных изменений — смены СУБД, реорганизации томов, обновления reverse proxy или перехода на другую ветку приложения. Именно такие изменения чаще всего делают старую процедуру восстановления недействительной.

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

PhotoView и ФотоМАСТЕР

Эти программы решают разные этапы работы. PhotoView нужен после того, как файлы уже лежат в архиве: он индексирует каталоги, строит веб-галерею, показывает EXIF, RAW, видео, карту и лица, даёт избранное и публичные ссылки. ФотоМАСТЕР, напротив, ориентирован на изменение отдельного изображения: ретушь портрета, пластику лица и фигуры, замену фона, удаление объектов, цветокоррекцию, фильтры и 3D LUT.

Если задача звучит «быстро привести портрет в порядок и убрать лишний объект», PhotoView не подходит по классу функций — исходник нужно открыть в редакторе. Если задача «дать домашним доступ к десяткам тысяч уже готовых фотографий на NAS, сохранив структуру папок», ФотоМАСТЕР не решает её как серверная медиатека. На практике эти инструменты могут дополнять друг друга: обработать кадр в редакторе, сохранить его в нужную папку, затем позволить PhotoView подхватить новый файл при сканировании.

PhotoView и PhotoPrism

PhotoPrism тоже умеет индексировать существующую библиотеку, показывает RAW и видео, распознаёт лица, строит карты и извлекает EXIF/XMP. Однако его каталогизационный слой заметно шире: есть комбинируемые поисковые фильтры по меткам, местоположению, разрешению, цвету и качеству, автоматические labels, более развитая работа с метаданными и WebDAV. Если основной вопрос — «найти среди большого хаотичного архива все снимки определённого содержания или сочетания признаков», PhotoPrism даёт больше инструментов.

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

PhotoView и Immich

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

Для существующего архива Immich умеет подключать External Libraries и имеет Folder View, но файловое дерево не является той же фундаментальной моделью альбомов, что в PhotoView. В PhotoView директория сразу соответствует album. В Immich внешняя библиотека индексируется в общую медиатеку, а папки доступны отдельным представлением; пользователь получает гораздо больше функций поверх данных, но и более сложный стек.

Если приоритет — автоматическое копирование с iPhone/Android, семантический поиск фразами, OCR и активная работа с библиотекой, Immich функциональнее. Если доставка файлов уже решена, а цель — максимально прямое отображение аккуратного дерева NAS с минимумом изменения исходной модели хранения, PhotoView остаётся понятнее.

Краткое сопоставление по задачам

Выбор определяется не количеством функций, а местом программы в рабочем процессе. PhotoView лучше раскрывается как слой просмотра поверх готовой файловой библиотеки. ФотоМАСТЕР нужен для изменения содержимого кадра. PhotoPrism делает акцент на богатой индексации и поиске, Immich — на полном цикле домашней фотоплатформы с мобильным резервным копированием.

Как настроить PhotoView для минимального обслуживания

Сначала сделайте файловую структуру предсказуемой. Используйте стабильный корень, не монтируйте временные каталоги и не включайте системные папки NAS. Затем задайте read-only доступ к оригиналам и отдельные записываемые тома для базы и кэша. Такая схема сразу отделяет ценные данные от легко пересоздаваемых.

На первом сканировании оставьте один worker. После успешного завершения включите периодический сканер и только потом повышайте параллелизм. Если библиотека содержит много видео, решите, нужен ли транскодинг и доступно ли аппаратное ускорение. Если лица не используются, отключите их анализ. Если RAW нужен только как архивный формат, но не для просмотра, рассмотрите отключение RAW processing или отдельный media path только с JPEG.

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

Открывать PhotoView в интернет стоит только после настройки HTTPS и дополнительного периметра. На текущем состоянии релизов отдельно проверьте, устранена ли CVE-2026-96271 в используемой сборке. Если нет, держите инсталляцию за VPN или в доверенной сети, особенно при нескольких пользователях.

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

Чек-лист после установки

• Оригиналы подключены к контейнеру по правильному внутреннему пути и доступны на чтение.
• Кэш и база находятся на постоянных томах, а не во временном слое контейнера.
• Первый пользователь видит только тот корень, который ему предназначен.
• Scan All завершается без ошибок и действительно добавляет медиа.
• Проверены несколько JPEG, RAW и видео из разных лет и камер.
• Timeline показывает разумные даты, а сортировка Albums соответствует ожидаемой.
• EXIF содержит камеру и параметры там, где они реально записаны в файлах.
• Places проверен на снимке с известными GPS-координатами и рабочим Mapbox token.
• People либо настроен и размечен, либо отключён, если функция не нужна.
• Periodic Scanner включён только после того, как стабильное ручное сканирование уже проверено.
• Для сервера с видео выбран приемлемый режим FFmpeg; GPU-ускорение протестировано отдельно.
• Публичные ссылки создаются только на нужные альбомы; ненужные shares удаляются.
• Внешний доступ закрыт TLS/VPN/прокси и не опирается исключительно на пароль PhotoView.
• Используемая сборка проверена на исправление актуальных проблем безопасности.
• Есть отдельная резервная копия оригиналов, базы и конфигурации, а восстановление проверено.

Итоговая логика использования

PhotoView стоит выбирать не как замену редактору или облачному фотосервису, а как интерфейс к уже существующему файловому архиву. Его сильная сторона — прямая связь с каталогами: пользователь продолжает управлять оригиналами привычным способом, а сервер добавляет удобный Timeline, Albums, EXIF, RAW-превью, видео, People, Places, избранное и sharing.

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

Для стабильной эксплуатации важнее не «максимально быстрый» сервер, а аккуратная конфигурация: read-only оригиналы, быстрый кэш, подходящая база, разумное число scanner workers, резервное копирование и защищённый внешний доступ. После этого PhotoView работает как тонкий каталогизационный слой, а не как единственная точка хранения — и именно в таком качестве его проще обслуживать и восстанавливать.