PhotoStructure: организация, поиск и дедупликация фотоархива

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

Что PhotoStructure делает с фотоархивом

Основная единица в PhotoStructure — не отдельный файл, а asset, то есть фотография или видеозапись как логический объект. У одного asset может быть несколько файловых вариантов: исходный RAW, JPEG из камеры, копия из резервной папки, уменьшенная версия из облачного экспорта и файл после обработки. Программа индексирует эти варианты, сравнивает метаданные и содержимое, объединяет подходящие экземпляры и в обычной галерее показывает один предпочтительный вариант. Поэтому число файлов на дисках закономерно может быть намного больше числа объектов, видимых в библиотеке.

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

Такой подход решает две разные задачи, которые часто ошибочно смешивают. Первая — удобная дедупликация представления: при пролистывании не приходится пять раз подряд видеть один кадр. Вторая — физическое хранение. PhotoStructure не обещает автоматически удалить все лишние копии на дисках. Напротив, при включённой автоматической организации она осторожно копирует каждый уникальный файловый поток в библиотеку, даже если несколько вариантов объединены в один asset. Совпадающий байт-в-байт файл повторно не копируется, но RAW, JPEG и отличающиеся метаданными версии могут сохраняться отдельно.

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

Какие данные попадают в библиотеку

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

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

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

Для обычного рабочего компьютера PhotoStructure поставляется как приложение для Windows 10 и новее, macOS Monterey и новее, а также для актуальных выпусков Ubuntu, Debian и Fedora на 64-битных x86-системах. Для домашнего сервера и NAS разработчик предлагает Docker и Node.js; Docker обозначен как рекомендуемый путь для большинства серверных установок. В текущей серверной ветке Node-вариант требует Node.js 24 или новее, тогда как настольные сборки и контейнер несут свой runtime.

После запуска нужно принять два принципиальных решения: где расположить библиотеку и где искать медиафайлы. Первое определяет место базы, превью и при необходимости организованных оригиналов. Второе задаётся scan paths — путями сканирования. На настольной системе папку можно выбрать через стандартный диалог, а на Docker-сервере путь должен существовать внутри контейнера и обычно соответствует bind mount.

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

Настройка путей сканирования

Раздел Settings с вопросом Any other places with photos or videos? управляет дополнительными источниками. PhotoStructure всегда сканирует собственную папку библиотеки. К ней добавляются явно указанные каталоги и, если установлен флажок Look in all volumes for photos and videos, обнаруженные смонтированные тома. Добавление нового пути немедленно ставит его в очередь синхронизации; удаление пути запрещает будущие проходы, но уже импортированные записи автоматически не уничтожает.

Для Docker особенно важно мыслить путями внутри контейнера. Если на хосте фотографии лежат в /mnt/photos, но примонтированы в контейнер как /ps/photos, в настройках PhotoStructure нужен именно контейнерный путь. Ошибка в этой точке часто выглядит как «программа не видит папку», хотя на самом деле процесс просто не имеет к ней маршрута или прав.

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

Первый импорт без риска для исходников

Для первого знакомства безопаснее начать с одной небольшой, репрезентативной папки: десятка RAW+JPEG, нескольких JPEG после обработки, видео, пары дублей и файлов с XMP. Так легче увидеть, как PhotoStructure агрегирует варианты, читает теги и даты, не дожидаясь обработки всего архива. После проверки добавляются крупные диски.

Если при старте предлагается установить дополнительные средства для видео и HEIF/HEIC, соглашаться имеет смысл только если эти форматы есть в архиве. Современные сборки умеют предложить установку FFmpeg и нужных декодеров с согласия пользователя. Без них JPEG и PNG продолжат работать, но часть видео или HEIF может не получить пригодного превью либо вообще не пройти импорт.

Какие файлы PhotoStructure импортирует и почему некоторые пропускает

Базовый набор включает JPEG, PNG, распространённые RAW цифровых камер и видео, которое способен декодировать FFmpeg. HEIF/HEIC зависит от доступности соответствующих инструментов. Само расширение не гарантирует импорт: файл проходит ряд фильтров и проверок, а причины отказа записываются в отчёт синхронизации.

По умолчанию слишком маленькие изображения и ролики отсеиваются. Для изображений минимальная сторона должна достигать 480 пикселей, для видео — 240 пикселей, а минимальный размер файла составляет 50 КБ. Эти пороги настраиваются параметрами minImageDimension, minVideoDimension и minAssetFileSizeBytes. Есть и верхний предел размера импортируемого файла, который особенно важен для длинных видео и может быть изменён через maxAssetFileSizeBytes.

Фильтры полезны против иконок, веб-миниатюр и технических картинок, но иногда именно они объясняют «пропажу» нужного скана. Если семейная фотография оцифрована в 400 пикселей по короткой стороне, она не появится при заводских порогах. Вместо бесконечного повторного сканирования следует открыть sync report, найти путь и проверить состояние excluded вместе с полем причины.

Проверка повреждений и RAW

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

При обнаружении повреждений разумно не пытаться «лечить» архив внутри PhotoStructure. Программа каталогизирует и диагностирует, но не является утилитой восстановления JPEG или RAW. Сначала следует восстановить исходник из резервной копии либо специализированным инструментом, затем пересканировать изменённый файл.

Автоматическая организация: копирование, а не перемещение

Опция automatic organization предназначена для тех, кто хочет не только индекс, но и аккуратный набор копий в едином месте. При её включении новые уникальные фото и видео копируются в библиотеку и раскладываются по датированным каталогам. Типовая схема выглядит как 2019/2019-05-01; исходное имя сохраняется. Если два разных файла с одной датой имеют одинаковое имя, PhotoStructure добавляет числовой суффикс и не перезаписывает существующий объект.

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

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

Изменение схемы каталогов

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

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

Надёжность копирования

Для копирования PhotoStructure умеет автоматически подбирать стратегию под файловую систему. Параметр fileCopyStrategy допускает встроенные и нативные варианты, а на поддерживающих copy-on-write файловых системах может применяться reflink. После копирования выполняется проверка контрольных сумм. Это особенно важно на NAS, где сочетание прав, особенностей SMB/NFS и временных файлов иногда делает обычное копирование менее предсказуемым.

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

Дедупликация и варианты одного кадра

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

Актуальные настройки предлагают три готовых режима сопоставления: Strict, Default и Lenient. Ранее вручную настроенные правила обозначаются как Manual. Строгий профиль уменьшает риск ошибочно склеить похожие, но разные кадры; мягкий повышает шанс собрать в один asset варианты, которые сильнее разошлись по метаданным. Универсально «правильного» режима нет: для серийной съёмки и сканов безопаснее консервативная настройка, для архива с массой облачных производных может быть полезнее более терпимая.

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

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

Если две фотографии неожиданно оказались одним объектом, сначала сравните их время съёмки, имена и метаданные. В серийной съёмке критичны доли секунды: если приложение или экспорт удалили субсекундное время, соседние кадры становятся труднее различимы. Для сложных случаев есть команда info, которая помогает понять, считает ли PhotoStructure два файла подходящими для одного asset.

Обратная проблема — очевидные копии остаются разными. Причиной часто оказывается серьёзное расхождение даты, геометрии, экспозиционных данных либо визуального отпечатка. Сначала имеет смысл убедиться, что это действительно одна фотография, а не похожие кадры серии. После этого можно аккуратно изменить профиль duplicate matching или отдельные пороги, но массово ослаблять правила ради одного исключения рискованно.

Иерархические теги вместо одной плоской ленты

В PhotoStructure все теги устроены как деревья. Путь Where/France/Paris/Louvre одновременно означает принадлежность к Лувру, Парижу и Франции. Аналогично Camera/Canon/EOS 5D наследует более общие уровни Canon и Camera. Это позволяет двигаться от широкого признака к конкретному, не создавая вручную сотни несвязанных меток.

Корневые категории формируются из разных источников: When — из времени съёмки, Camera и Lens — из метаданных оборудования, filesystem — из путей, Who — из данных о людях, Albums — из альбомных метаданных, Keywords — из ключевых слов, Where — из GPS и текстовых мест, Event и What — из соответствующих тегов. Один кадр одновременно присутствует в нескольких фасетах, но физически остаётся одним asset.

Вместо бесконечного списка лет интерфейс использует samples: на уровне When показываются небольшие визуальные выборки дочерних лет, затем месяцев и более глубоких уровней. Тот же принцип применяется к другим иерархиям. Такой режим особенно полезен для «прогулки» по архиву, когда пользователь не помнит точную дату или имя файла, но узнаёт событие визуально.

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

Файловая структура тоже становится тегами

PhotoStructure не заставляет отказаться от старых папок. Путь исходника превращается в файловую иерархию, поэтому каталоги вроде Trips/2024/Italy остаются доступны как способ навигации. Это удобно при миграции из коллекции, где смысл годами был зашит именно в названия каталогов.

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

Поиск: от имени файла до сложного запроса

Строка поиска понимает как свободный текст, так и фильтры. Обычное слово ищется по тегам, отображаемым названиям и именам файлов. Если в архиве есть napa-sunset.jpg или папка с Napa в файловом пути, запрос napa способен найти соответствующий asset без указания специального поля.

Для точной выборки применяются префиксы. camera:canon ограничивает совпадения камерой, lens:50mm — объективом, type:video — типом, who:alice — категорией Who, kw:sky — ключевыми словами, fs:backup — файловым путём. Для имени есть name: и синонимы file:, fn:, filename:, basename:.

Точное имя задаётся выражением вроде name:=IMG_0012.JPG. Шаблон name:*.jpg находит JPEG по расширению, а -name:screenshot исключает имена с указанным фрагментом. Знак равенства доступен и в теговых фильтрах: например, where:="san francisco" точно выбирает соответствующий узел тега, сохраняя совпадения его дочерних ветвей; в name: он ограничивает совпадение самим именем файла.

По времени доступны date:, before:, after: и updated:. Дата может задаваться годом, годом и месяцем либо полным днём. Поддерживаются операторы сравнения. Например, after:2018 before:2022 type:video ограничит выдачу видео соответствующим периодом.

Условия объединяются через AND и OR, используются скобки, а пробел между условиями эквивалентен AND. Практический запрос faved AND (who:alice OR date:2020-07-04) ищет избранные материалы, где встречается Alice либо совпадает дата. Для пути тега можно включать слеши, а фразы с пробелами заключать в кавычки.

Метаданные, XMP и побочные файлы

PhotoStructure строит значительную часть каталога не из собственной разметки, а из уже существующих метаданных. При импорте учитываются данные внутри фото и видео, XMP и другие поддерживаемые sidecar-файлы, а также JSON рядом с материалами из облачных экспортов. Такой подход удобен, если архив раньше обслуживался Lightroom, digiKam, Picasa, Bridge или утилитами на базе ExifTool: накопленные ключевые слова и часть другой разметки не приходится вводить заново.

Для ключевых слов PhotoStructure читает несколько распространённых полей, в том числе HierarchicalSubject, Keywords, Subject, XPKeywords и ряд совместимых вариантов. Простые значения помещаются под корень Keywords, а иерархические превращаются в дочерние пути. Разделители путей и списков настраиваются, что важно для старых коллекций, где разные программы использовали несовместимые правила.

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

Почему один sidecar иногда важнее самого JPEG

У фотографии может быть несколько источников сведений: встроенный EXIF, XMP рядом с оригиналом, JSON после Google Takeout и метаданные другого варианта того же asset. PhotoStructure умеет объединять информацию из вариантов, поэтому более качественный исходник не обязательно является единственным источником описания. Например, уменьшенная облачная копия может принести полезное имя человека или подпись, которой нет в локальном RAW.

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

Запись тегов из PhotoStructure

В актуальном интерфейсе PhotoStructure PLUS позволяет изменить теги одного asset. Откройте фотографию, покажите панель Info, нажмите Edit tags, затем используйте + Add в секциях Who, Album, Event, What или Keyword. После Save выбранный набор записывается в настроенное место назначения метаданных. Перед записью программа перечитывает доступные варианты asset и применяет согласованный набор к ним, чтобы не редактировать устаревшее состояние.

Редактор сначала ищет уже существующие пути и отдельно предлагает создать новое значение, если точного совпадения нет. Подсказки учитывают недавно использованные теги и теги соседних кадров. Это снижает вероятность породить почти одинаковые варианты вроде Vacation/Italy и vacation/italy, хотя окончательную структуру всё равно задаёт пользователь.

Не каждый видимый тег редактируем. Значение, полученное из общего файла метаданных каталога, имени папки или неподдерживаемой для записи структуры, может отображаться заблокированным. Подсказка объясняет источник. Это предохраняет от ситуации, когда изменение одного asset неожиданно изменило бы общий metadata-файл для десятков фотографий.

Люди и категория Who: импорт имён без собственного распознавания лиц

PhotoStructure не выполняет собственное автоматическое распознавание лиц. Она умеет прочитать сведения о лицах и именах, которые уже записали другие программы. Поддерживаются совместимые face regions в метаданных MWG, встречающиеся после Picasa, Lightroom Classic, digiKam и других инструментов, а также данные о людях из Google Takeout и некоторые настраиваемые текстовые поля.

Практическое следствие простое: если архив уже размечен в другой DAM-системе, категория Who может заполниться автоматически. Если же исходные файлы никогда не содержали имён и областей лиц, PhotoStructure сама не просмотрит коллекцию и не создаст кластеры людей. Для этой задачи нужен внешний инструмент с face detection/recognition, после чего его метаданные можно перечитать.

Ручная команда + Add в Who создаёт связь человека с asset целиком. Это полезно для видео, животных, человека за кадром или лица, которое внешний алгоритм не распознал. Но команда не рисует рамку лица и не превращается в встроенный face recognizer. Если удалить имя, пришедшее из редактируемой face region, PhotoStructure может убрать идентичность, сохранив геометрию области.

Формат имён и семейные иерархии

По умолчанию tagNamesFormatter равен as-is, поэтому имя вроде Albert Einstein хранится непосредственно под Who без попытки угадать фамилию. Это консервативный вариант: порядок имён различается по культурам, а автоматическое разбиение легко ошибается.

Для архивов с единообразными именами доступны схемы family/given и family/fullname. Параметр tagNamesOrder принимает варианты givenFirst и surnameFirst, а tagNamesDefaultFamily помогает управлять однословными именами. Перед применением на всей библиотеке правила лучше проверить на нескольких характерных файлах командой info с временными настройками.

Альбомы, события и ручная систематизация

Корень Albums заполняется из метаданных. PhotoStructure читает, в частности, XMP Album, совместимые MWG Collections и данные альбомов из Google Takeout. Вложенные названия могут образовывать иерархию. При этом коллекции Lightroom, записанные как CatalogSets, относятся к Keywords, а не автоматически превращаются в Albums — это важно при переносе сложной структуры из Lightroom Classic.

Ручное редактирование альбома в PhotoStructure работает по одному asset. Панель Info → Edit tags позволяет добавить или удалить его Album-тег, но полноценного пакетного менеджера альбомов, где выделяется сотня файлов и одним действием создаётся общий альбом, нет. Для больших ручных подборок это одно из заметных ограничений текущего интерфейса.

Event и What редактируются тем же механизмом тегов. Логика остаётся иерархической: событие можно сделать общим родителем для нескольких уточняющих веток. Главное — заранее договориться с собой о семантике. Если часть отпусков хранится в Albums, часть в Event, а часть в Keywords, поиск продолжит работать, но навигация станет менее предсказуемой.

Что делать с существующей папочной классификацией

Нет необходимости сразу переписывать старую структуру в новые теги. Сначала импортируйте папки и убедитесь, что filesystem-иерархия уже даёт приемлемую навигацию. Затем добавляйте семантические теги только там, где они решают конкретную проблему: один человек встречается в сотне папок, одно место снято в разные годы, один проект хранится на нескольких дисках.

Такой постепенный подход лучше тотального «перетегивания» архива. PhotoStructure сильна именно тем, что объединяет несколько систем координат — время, путь, камеру, место, альбом, человека и ключевые слова — и не требует выбрать одну-единственную.

Места: категория Where и локальное обратное геокодирование

Если файл содержит GPSLatitude и GPSLongitude, PhotoStructure может получить страну, регион, подрегион и город через географическую базу, поставляемую с ExifTool. Запрос во внешний геокодирующий сервис для этого не требуется. Встроенная база охватывает примерно 115 тысяч городов по миру с порогом населения от нескольких тысяч человек.

Результат становится иерархией Where. Если GPS не хватает, используются явные поля Country, State, County, City, Location и совместимые поля LocationShown/LocationCreated. В современных настройках написанные в метаданных названия места имеют приоритет там, где они противоречат автоматически полученному варианту. Шаблон и список синонимов полей можно изменять продвинутыми параметрами.

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

Если координат нет вообще, Where не угадывает место по содержимому изображения. В таком случае геотег лучше записать внешним редактором или через XMP, затем запустить sync. Ручное редактирование Where из текущего тег-редактора не относится к поддерживаемым операциям.

Дата съёмки: почему PhotoStructure не полагается только на время файла

Для построения When PhotoStructure последовательно ищет надёжный capture time. Сначала рассматриваются EXIF/IPTC-поля вроде DateTimeOriginal и их варианты с субсекундами. Если их нет, программа проверяет ISO-подобные даты в имени и пути, затем менее строгие датированные имена, может оценить интервал по соседним файлам и только ближе к концу цепочки обращаться к файловым timestamp.

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

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

Импорт из Apple Photos

Современные версии PhotoStructure умеют читать не только файлы внутри библиотеки Apple Photos, но и её базу Photos.sqlite. Это важно, потому что альбомы, именованные люди, ключевые слова, заголовки, описания, скорректированные даты и часть мест могут существовать только в базе Photos и отсутствовать в JPEG/HEIC.

На Mac следует убедиться, что оригиналы действительно загружены локально, если используется iCloud Photos. Затем PhotoStructure нужен Full Disk Access, а в scan paths выбирается вся папка Photos Library.photoslibrary, а не только внутренний каталог originals. База читается рядом с файлами в режиме без записи: PhotoStructure не вносит изменения обратно в Apple Photos.

Импортированные альбомы становятся Album-тегами, именованные люди — Who, ключевые слова — Keywords; даты и координаты могут дополнять сведения файла по правилам приоритета. В актуальной стабильной ветке чтение этих метаданных доступно и в LITE. Если включена автоматическая организация PLUS, PhotoStructure может записать полученные сведения в XMP-sidecar рядом с организованной копией, чтобы они не зависели исключительно от оригинальной базы Apple.

Старые библиотеки iPhoto/Aperture с photos.db этим механизмом не поддерживаются. Копия современной Photos Library на другом компьютере работает только если сохранена целостная структура с originals и database/Photos.sqlite. Экспортированные «россыпью» изображения без базы уже не могут восстановить альбомные связи, которые никогда не были записаны в сами файлы.

Импорт Google Photos через Takeout

Для переноса из Google Photos надёжнее использовать полный Google Takeout, а не скачивать альбомы по одному. Экспорт часто разбивается на несколько ZIP или TGZ, причём связанные фото и JSON-метаданные могут попасть в разные части. Поэтому все части следует распаковать в один общий каталог либо смонтировать как единое виртуальное дерево, после чего добавить его в scan paths.

PhotoStructure читает JSON-sidecar из Takeout, связывает их с медиа и извлекает доступные альбомы, людей и другие сведения. Это один из сценариев, где дедупликация особенно полезна: в локальном архиве может уже лежать оригинал камеры, а Takeout приносит тот же кадр с другой метаобвязкой. Программа может объединить варианты и взять полезные метаданные из облачной копии, не заставляя пользователя вручную выбирать один источник.

Если после импорта появились дубли, сначала проверьте, что все части Takeout действительно объединены в одну структуру и JSON лежат рядом с соответствующими файлами. Отдельная обработка каждого архива повышает вероятность того, что связь временно не будет видна. Второй источник проблем — изменённые Google имена с числовыми суффиксами; современные правила PhotoStructure учитывают распространённые производные, но крайние случаи всё равно требуют проверки.

Просмотр фотографий и видео

Открытый asset показывается поверх текущей галереи, поэтому контекст не теряется. Можно переходить к предыдущему или следующему объекту внутри текущей выборки, пользоваться плёнкой соседних кадров, а затем вернуться к той же позиции в галерее. В браузере Back и Forward учитывают просмотренные assets; клавиша Esc или X закрывает оверлей.

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

В заголовке viewer отображаются дата и место, если они известны. Info показывает технические сведения, теги и известные файловые варианты. Щелчок по пути конкретного варианта переключает отображаемый файл, что удобно для проверки RAW/JPEG или нескольких отредактированных копий. Для RAW и HEIF современные версии умеют при доступном декодере дать детальный зум исходника; обычная навигация по-прежнему опирается на подготовленные превью ради скорости.

Избранное, поворот и меню asset

В заголовке доступны действия favorite, поворот, архивирование, удаление из библиотеки и удаление с диска. На узком экране они уходят в меню с тремя точками. Команда Re-sync this asset полезна после внешнего изменения метаданных конкретного файла и быстрее полного прохода по большому диску.

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

Превью и видео: баланс качества, места и нагрузки

Для быстрых галерей PhotoStructure заранее создаёт несколько размеров изображений. В актуальных настройках максимальное фото-превью по умолчанию укладывается в 4096×2160, а видео — в 1920×1080 или 1080×1920 в зависимости от ориентации. В интерфейсе эти уровни представлены понятными вариантами от 480p до 8K. Программа не увеличивает изображение выше исходного разрешения.

Параметр previewCacheProfile управляет количеством промежуточных размеров. Профили Minimum, Small, Balanced, Large и Maximum позволяют обменять дисковое пространство на объём передаваемых данных и скорость открытия. Balanced является исходной точкой. Чем больше размеров хранится, тем чаще браузер получает превью, близкое к реально требуемому, но тем больше занимает кэш.

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

Видео, которое браузер не умеет воспроизводить напрямую, может перекодироваться в совместимую версию. Современный типовой кодек — H.264; при необходимости transcodeVideoCodec настраивается, включая HEVC/H.265 там, где вся клиентская среда его поддерживает. Если transcodeVideos=false, миниатюры могут остаться, но часть роликов не получит сгенерированной версии для воспроизведения в браузере.

Когда нужны FFmpeg и HEIF-инструменты

FFmpeg используется для видео и на ряде платформ для HEIF/HEIC. PhotoStructure умеет предложить установку необходимых инструментов без прав администратора через подходящий пакетный менеджер, однако сама программа не является поставщиком кодеков. В Docker установка также выполняется в конфигурационной области контейнера.

Если HEIC виден как ошибка или видео не запускается, первым делом откройте Health и проверьте Video support/HEIF support. Затем убедитесь, что найден именно актуальный executable и что процесс PhotoStructure имеет к нему доступ. Простое наличие ffmpeg в интерактивном shell не гарантирует, что тот же PATH видит сервис или контейнер.

Архивирование, удаление из каталога и удаление с диска

Три действия имеют разные последствия. Archive скрывает asset из обычных миниатюр, но сохраняет запись в библиотеке и файлы на диске. Найти его можно запросом archived:true. Горячая клавиша — Shift+A.

Remove from library предназначено для объекта, который не нужен в каталоге, но должен остаться на диске. Сначала asset помечается, а окончательное исключение выполняется из представления удалённых объектов командой Remove assets. Известные варианты блокируются от обычного автоматического повторного импорта. Горячая клавиша — Shift+R.

Delete ставит asset в очередь на удаление и из библиотеки, и с файловой системы. Фактическая операция происходит после Empty trash. PhotoStructure удаляет только варианты, которые в этот момент доступны на смонтированных томах; выключенный внешний диск не получит «отложенную» команду удаления через месяц. Горячая клавиша — Shift+T.

На Windows, macOS и обычном Linux программа по умолчанию старается использовать системную корзину, если возможно. В Docker trySoftDeletes по умолчанию выключен, поскольку контейнерная корзина требует корректной XDG-конфигурации на bind mounts. Перед включением жёсткого удаления полезно проверить процесс на тестовом наборе файлов и убедиться в наличии независимой резервной копии.

Есть дополнительная защита для открытых по сети библиотек. Если интерфейс доступен по LAN без аутентификации, потенциально опасные подтверждающие операции Remove assets и Empty trash по умолчанию отключаются. Это не заменяет сетевую безопасность, но снижает риск случайного удаления посетителем.

Синхронизация и перестроение библиотеки

В PhotoStructure синхронизация и rebuild — разные операции. Sync смотрит прежде всего на файловую систему: обходит scan paths, находит подходящие файлы, проверяет изменившиеся медиа и sidecar, импортирует новое и сопоставляет состояние диска с базой. Rebuild работает с уже известной библиотекой: перечитывает или переоценивает сведения, повторно агрегирует assets, обновляет превью и применяет новые алгоритмы тегирования или дедупликации.

Обычный sync состоит из нескольких фаз. Сначала каталог рекурсивно сканируется. Затем подходящие файлы и связанные sidecar проходят обработку; неизменившиеся объекты не должны полностью импортироваться заново. После этого PhotoStructure проверяет, что стало с ранее известными путями: действительно ли файл удалён, временно недоступен из-за отключённого тома или остался на месте.

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

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

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

Расписание и ручной запуск

PhotoStructure умеет периодически синхронизировать тома автоматически; типовая конфигурация запускает ночной проход, а параметр syncCron позволяет изменить расписание или отключить автоматический запуск. Ручной Sync now полезен после массового изменения тегов внешним редактором, подключения нового архива или устранения ошибки доступа.

Не стоит запускать полную повторную синхронизацию после каждого изменения одной фотографии. Для отдельного asset есть точечный re-sync, а для одной папки System activity позволяет перезапустить именно её. Это экономит I/O на больших NAS и быстрее даёт результат.

System activity: что происходит прямо сейчас

Меню Admin → System activity показывает состояние фоновой обработки. Раздел Admin изначально может быть свёрнут. На странице видны активная синхронизация, Library Metrics, live feed, просканированные папки, временные показатели и отчёты. Эта страница полезнее бездумного ожидания: по ней видно, обходит ли программа каталоги, импортирует ли файлы, ждёт ли I/O или остановилась из-за проблемы.

В блоке Scanned folders каждая папка имеет отдельную статистику: сколько файлов импортировано, исключено, находится в обработке или завершилось ошибкой. Рядом доступен Sync now. Если один внешний диск ведёт себя плохо, это сразу отделяется от остальных источников.

Library Metrics помогает правильно интерпретировать числа. Assets — уникальные видимые фото и видео после дедупликации. Image files и Video files — количество отслеживаемых путей файлов. Если включена automatic organization, файловых путей закономерно становится больше: программа видит исходный экземпляр и организованную копию. RAW+JPEG, редакторские версии и резервные копии также увеличивают file count без такого же роста asset count.

Sync reports: ответ на вопрос «почему файл не появился»

Каждый проход создаёт подробный отчёт синхронизации. В интерфейсе его можно открыть в System activity, следить за новыми строками через Follow и фильтровать по импортированным, не импортированным, ошибочным файлам, просканированным и исключённым папкам. Скачиваемая выборка соответствует активному фильтру, поэтому не обязательно выгружать весь огромный журнал.

На диске отчёты находятся внутри .photostructure/sync-reports/ и используют JSON Lines: одна строка — одно событие. Для каждого пути важным является последнее событие, поскольку отчёт append-only. Это удобно для grep, ripgrep, jq и последующего анализа в таблице.

Полезные финальные состояния файла: imported — новый объект принят, updated — известный файл изменился и перечитан, unchanged — изменений нет, copied — создана организованная копия, excluded — сработал фильтр, unavailable — источник временно недоступен, absent — путь действительно исчез на доступном томе, failed — произошла ошибка, timeout — операция превысила лимит времени.

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

Практический разбор пропавшего файла

1. Откройте Admin → System activity и выберите отчёт того прохода, когда каталог должен был сканироваться.
2. Найдите полный путь файла, а не только basename: одинаковое имя может встречаться на нескольких томах.
3. Если состояние excluded, прочитайте details. Частые причины — размер, разрешение, неподдерживаемый формат или исключённая папка.
4. При unavailable проверьте, смонтирован ли диск или bind mount и не изменился ли контейнерный путь.
5. При failed перейдите к Logs и сопоставьте время ошибки; затем исправляйте права, кодек или повреждение файла.
6. После устранения причины запустите sync только для нужного пути.

Такой порядок быстрее, чем менять настройки вслепую. В PhotoStructure почти каждое решение импортера оставляет диагностический след.

Logs: ошибки, предупреждения и диагностика

Страница Admin → Logs предназначена для внутренних сообщений программы. Верхний блок Errors & Warnings фильтруется по FATAL, ERROR и WARN, интервалу от последнего часа до нескольких дней и произвольному тексту. Строку можно раскрыть и посмотреть контекст.

Ниже находится Log Files с фильтрами MAIN, WEB, SYNC, WORKER и FATAL. Отдельные журналы скачиваются напрямую. Это полезно, когда проблема появляется только в одном worker или при работе веб-части, а общий список предупреждений слишком шумный.

Меню Actions содержит два целевых способа собрать диагностику. Temporal Diagnostics формирует пакет журналов и sync reports вокруг указанного времени, а File Diagnostics ищет записи по конкретному файлу или пути. Для воспроизводимой ошибки это точнее, чем отправлять всю историю работы библиотеки.

Уровень error является нормальной исходной настройкой. info и особенно debug дают намного больше сведений, но увеличивают объём логов и снижают производительность. Повышайте детализацию только на время диагностики и возвращайте logLevel к обычному значению после воспроизведения проблемы.

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

Health и профилактика проблем

Health checks проверяют состояние, которое трудно диагностировать по одной фотографии: права на каталоги, доступность инструментов импорта, свободное место, структуру базы, корректность настроек и некоторые особенности томов. Индикатор здоровья доступен из интерфейса; после исправления причину можно перепроверить без полного перезапуска всей библиотеки.

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

На сервере полезно отличать health-проблему от отсутствующего source volume. Выключенный USB-диск — нормальная временная ситуация, если библиотека умеет идентифицировать том. Ошибка записи в .photostructure — уже критична, потому что база и служебные файлы должны быть доступны на запись процессу PhotoStructure.

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

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

Синхронизация умеет адаптировать число параллельных импортов к загрузке процессора. Параметр cpuBusyPercent задаёт целевой уровень, а maxConcurrentImports остаётся жёстким потолком. В типовой конфигурации целевое значение CPU составляет 75 процентов. На рабочей станции его можно снизить, если импорт мешает другим задачам; на выделенном сервере допустимо дать процессу больше ресурсов.

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

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

Не ускоряйте импорт ценой перегрева и ошибок

На Linux PhotoStructure умеет учитывать температурные датчики и приостанавливать тяжёлую работу при превышении порогов для CPU, HDD и SSD. Это особенно актуально для мини-серверов и NAS с плотной компоновкой. Если синхронизация периодически «сама тормозит», проверьте System activity и датчики прежде, чем принудительно увеличивать число worker.

Принцип тот же для диска: современные версии учитывают свободное пространство и могут откладывать операции, если производство превью или копий стало опасным. Увеличение concurrency не поможет, если реальный лимит — запись на медленный HDD или нехватка места.

Настройка объёма превью

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

Если интерфейс используется в основном с телефона через локальную сеть, 8K-превью обычно не дают пользы, а кэш разрастается. Если PhotoStructure выводится на большой 4K/5K-монитор и оригиналы часто лежат на отключаемых дисках, слишком низкое качество превью, наоборот, ухудшит просмотр. Оптимум определяется реальным клиентским оборудованием.

Продвинутые настройки: интерфейс, TOML и переменные среды

Основные параметры доступны на Settings, а редкие настройки спрятаны, чтобы не перегружать интерфейс. В текущих версиях advanced settings можно раскрыть при необходимости, и браузер запоминает выбор. Для системного администратора остаются два TOML-файла и переменные среды.

System settings относятся к конкретной машине: scan paths, логи, ограничения CPU и другие параметры окружения. Типовые пути: ~/.config/PhotoStructure/settings.toml в Linux, ~/Library/Application Support/PhotoStructure/settings.toml в macOS, %APPDATA%PhotoStructuresettings.toml в Windows и bind mount /ps/config/settings.toml в Docker.

Library settings относятся к фототеке и хранятся в <library>/.photostructure/settings.toml. Здесь находятся правила превью, автоматической организации, тегирования и дедупликации. Такое разделение позволяет переносить библиотеку на другой компьютер, не перетаскивая в неё аппаратно-зависимые пути и ограничения старой системы.

Большинство параметров можно переопределить переменными среды с префиксом PS_ и именем в верхнем регистре. Например, PS_LOG_LEVEL влияет на журналирование, а PS_LIBRARY_DIR задаёт библиотеку. Переменная среды имеет более высокий приоритет, поэтому «не меняющаяся» настройка в интерфейсе часто объясняется активным override. Современный Settings показывает, когда значение перекрыто внешней переменной.

Что не стоит менять без причины

Пороги image hash, эвристики дат и низкоуровневые параметры файлового копирования взаимосвязаны. Изменение одного числа может перестроить состав assets во всей библиотеке. Если проблема локальна, сначала используйте готовые профили Strict/Default/Lenient, sync report и info. Ручной тюнинг нужен после того, как понятен конкретный тип ложного совпадения.

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

Доступ с других устройств и безопасность сети

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

В опубликованных на текущий момент сборках нет встроенного входа по логину и паролю. Настольная установка вне Docker обычно слушает только локальную машину. Параметр exposeNetworkWithoutAuth=true заставляет процесс принимать сетевые подключения, но сам по себе не добавляет аутентификацию.

Поэтому безопасный удалённый доступ следует строить через приватную сеть, VPN либо HTTPS reverse proxy с собственной аутентификацией. Публиковать открытый порт PhotoStructure в интернет нельзя считать нормальной конфигурацией. Особенно опасно делать это там, где включены операции удаления файлов.

Для домашнего LAN тоже полезно определить модель доверия. Если Wi‑Fi доступен гостям или IoT-устройствам, «локальная сеть» не равна «доверенная сеть». Разделение VLAN, VPN для личных клиентов и прокси с учётной записью дают предсказуемый контроль, не зависящий от планируемых функций будущих версий.

Практический сценарий: собрать архив с нескольких дисков

Типичная исходная ситуация — годы фотографий на системном SSD, старом USB HDD, NAS и резервной копии ноутбука. Цель первого этапа — не удалить дубли, а увидеть всю структуру и убедиться, что PhotoStructure правильно объединяет очевидные варианты.

1. Создайте библиотеку на накопителе с запасом места для базы и превью.
2. Отключите automatic organization, если пока не готовы создавать вторую копию всех уникальных файлов.
3. Добавьте каждый источник как отдельный scan path или включите сканирование всех нужных томов.
4. Дождитесь хотя бы первого прохода и сравните Library Metrics: assets должны быть меньше file count там, где много дублей и RAW+JPEG.
5. Откройте несколько заведомых дублей через Info и проверьте список вариантов.
6. Проверьте When, filesystem, Camera и Search, чтобы убедиться, что метаданные читаются ожидаемо.
7. Только после этого решайте, нужна ли automatic organization и какой режим duplicate matching подходит коллекции.

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

Практический сценарий: RAW+JPEG и редакторские версии

Фотографу часто важно сохранить RAW как мастер, камерный JPEG для быстрого просмотра и несколько экспортов. PhotoStructure может объединить их в один asset, если даты и визуальные признаки достаточно согласованы. В галерее показывается выбранный предпочтительный вариант, но Info сохраняет доступ к остальным.

Не используйте физическое удаление только потому, что PhotoStructure сгруппировала файлы. RAW и JPEG несут разные данные; TIFF после ретуши может быть нужен для печати, а маленький JPEG — для отправки. Дедупликация интерфейса здесь означает «это представления одного снимка», а не «эти файлы взаимозаменяемы».

Если внешний редактор пишет XMP рядом с RAW, добавьте sidecar в ту же файловую структуру и разрешите PhotoStructure его читать. После правки метаданных выполните re-sync asset или папки. Тогда теги и даты обновятся без полного rebuild.

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

Если лица уже размечены в digiKam, Lightroom или старой Picasa, сначала сохраните совместимые метаданные в файлах или XMP, а затем импортируйте. Who заполнится из готовых имён. Для неразмеченных кадров PhotoStructure не создаст людей автоматически, поэтому стоит заранее решить, нужен ли отдельный face-recognition инструмент.

География обычно требует меньше ручной работы: смартфоны пишут GPS, а PhotoStructure локально превращает координаты в Where. Для старых камер без GPS можно сначала добавить координаты внешним редактором или хотя бы город/страну в XMP. После sync фотографии окажутся в общей иерархии мест независимо от года и папки.

Для событий используйте один тип тега последовательно. Например, семейные поездки — Event, подборки для печати — Albums, общие описательные свойства — Keywords. Это делает поиск вроде who:Anna where:Italy after:2018 понятным и устойчивым.

Практический сценарий: NAS и отключаемые внешние диски

Если оригиналы лежат на NAS, библиотеку можно разместить там же, но для отзывчивого интерфейса часто выгоднее локальная база и превью. На Windows сетевой ресурс лучше монтировать устойчивым способом, а в Docker — объявить bind mount с постоянным контейнерным путём. Изменение mount path без понимания volume identity способно породить дополнительные файловые пути.

PhotoStructure старается идентифицировать том не только по букве диска или mount point. Это помогает узнавать один и тот же USB-накопитель после переподключения. Но если клонировать том вместе с пользовательским UUID и одновременно подключить обе копии, идентичность становится неоднозначной. Для клона нужен новый уникальный идентификатор.

Отключённый диск не следует путать с удалёнными файлами. Пока volume недоступен, записи могут считаться unavailable. Только когда том действительно смонтирован и программа видит родительский каталог, отсутствие конкретного файла становится основанием считать его исчезнувшим.

Практический сценарий: миграция метаданных без смены редактора

PhotoStructure не обязана становиться единственным редактором метаданных. Можно продолжать использовать Lightroom Classic, digiKam или ExifTool как систему записи, а PhotoStructure — как быстрый индекс и просмотрщик. Главное условие: изменения должны попадать в поддерживаемые поля или sidecar, которые видит синхронизация.

После крупной правки каталога внешним приложением запустите sync. PhotoStructure сравнит размеры и времена изменения, перечитает нужные файлы и sidecar, затем обновит tags. Если вы изменили правила интерпретации самих тегов — например, разделители Keywords или формат имён Who — может потребоваться более широкая повторная обработка.

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

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

Файл лежит в папке, но его нет в галерее

Сначала проверьте, что папка вообще входит в scan paths и том смонтирован. Затем найдите путь в sync report. excluded почти всегда укажет конкретный фильтр: минимальный размер, разрешение, расширение, скрытый каталог, NoMedia или пользовательский glob. unavailable указывает на доступность тома, а failed требует просмотра Logs.

Если файл изменён внешним редактором, но PhotoStructure продолжает показывать старое состояние, выполните re-sync asset или соответствующей папки. Rebuild всей библиотеки здесь избыточен.

HEIC не импортируется или выглядит пустым

Откройте Health и проверьте HEIF support. На некоторых системах достаточно системного декодера, на других нужен современный FFmpeg или libheif. Если PhotoStructure предложила установить инструменты, завершите установку и повторите целевой sync. На сервере также проверьте PATH процесса, а не пользовательского терминала.

Видео видно как миниатюру, но оно не играет

Это обычно означает, что исходный кодек не поддерживается клиентским браузером, а совместимая транскодированная версия не создана. Проверьте Video support, наличие FFmpeg, свободное место и настройку transcodeVideos. В sync report посмотрите, не было ли timeout или failed на конвертации.

Импорт идёт очень медленно

Определите фазу. Если долго Scanning — узкое место может быть в файловой системе или сетевой задержке. Если Processing занят RAW и видео — нагрузка закономерно CPU-интенсивна. Если worker часто приостанавливаются, проверьте CPU, температуры и свободное место. Увеличивать maxConcurrentImports имеет смысл только когда хранилище и охлаждение действительно простаивают.

После обновления программа «снова всё обрабатывает»

Это может быть rebuild, а не потеря базы. Обновления иногда требуют перерасчёта метаданных, группировки assets или превью. Откройте статус и дождитесь завершения. Rebuild можно прервать перезапуском — он продолжится. Если automatic organization выключена, подключите внешние диски, с которых были импортированы исходники.

Два разных кадра склеились в один asset

Проверьте субсекундное время, визуальную похожесть и режим duplicate matching. Для burst-серий начните со Strict. Не меняйте сразу десяток imageHash* параметров. Если проблема сохраняется, сравните конкретные файлы через диагностическую команду info и только затем корректируйте пороги.

Один и тот же снимок показывается как два assets

Сравните capture time, размеры, поворот и метаданные. Облачная копия могла получить неверную дату, а отредактированная версия — существенно измениться. Убедитесь, что это действительно вариант того же кадра, после чего попробуйте Default или Lenient на тестовой библиотеке. Мягкий профиль повышает риск ложных объединений, поэтому результат проверяют на сериях похожих фотографий.

Теги есть в Lightroom, но PhotoStructure их не видит

Убедитесь, что Lightroom записал сведения в файл или XMP, а не хранит их только в собственном каталоге. Проверьте название поля: CatalogSets, например, интерпретируется иначе, чем Album. Затем re-sync. Если иерархия развалилась, проверьте разделители Keywords и формат исходного XMP.

Who пустой, хотя на снимках есть лица

PhotoStructure не распознаёт лица самостоятельно. Нужны уже записанные person/face metadata. Проверьте, создал ли исходный инструмент MWG RegionList или совместимые поля. Простого наличия лица на пикселях недостаточно.

Where показывает неправильный город

Сравните GPS с явными полями City/Country. Если координата далека от известных населённых пунктов, локальная база может выбрать нежелательный вариант в пределах порога. Точнее всего исправить метаданные источника и пересинхронизировать. Глобальное увеличение tagGeoMaxDistanceKm ради одной фотографии может ухудшить весь архив.

Settings меняется, но значение возвращается назад

Проверьте, не задана ли соответствующая переменная среды PS_*. Она имеет более высокий приоритет, чем TOML и UI. В Docker источник часто находится в compose-файле или environment секции. Удалите override либо измените его там, где запускается контейнер.

После переноса Docker каталог пуст

Проверьте bind mounts и контейнерные пути. PhotoStructure не может автоматически угадать, что старый /ps/photos теперь стал /media/photos. Библиотека и исходники должны быть примонтированы в ожидаемые точки, а UID/GID процесса — иметь нужные права. Не создавайте новый пустой каталог поверх места, где контейнер ожидал старый mount.

Логи разрастаются

Если временно включали info или debug, верните logLevel=error. Высокая детализация предназначена для диагностики и может заметно увеличивать I/O. Для разовой проблемы лучше использовать Temporal Diagnostics и встроенный flight recorder.

Поисковые рецепты для реального архива

Синтаксис поиска полезнее всего не в виде справочника операторов, а как набор повторяемых сценариев. Если нужно найти все видео определённого периода, сочетайте тип и диапазон дат: type:video after:2020-01 before:2021-01. Для фотографий конкретного человека на одной камере можно использовать who:"Anna Petrova" camera:Sony. Если имя известно только приблизительно, начните с короткой части и уточняйте результат другими фильтрами.

Поиск по имени файла удобен при общении с типографией, клиентом или архивистом, когда в задаче фигурирует техническое имя. name:=DSC_1234.ARW ищет точное имя, а name:DSC_1234 допускает совпадения по фрагменту. Если нужно быстро исключить систематические скриншоты, запрос можно дополнить -name:screenshot или файловым фильтром по соответствующей папке.

Поиск по обновлению отличается от даты съёмки. updated: отвечает на вопрос «что недавно изменилось в библиотеке», а не «когда сделан кадр». Он удобен после массового импорта или редактирования метаданных: можно проверить только свежепереиндексированные assets, не просматривая весь архив.

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

Контроль данных перед массовым удалением

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

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

Не следует использовать команду Delete как средство «физической дедупликации по варианту»: действие применяется к asset и известным доступным вариациям согласно логике корзины. Если требуется аккуратно оставить один файл из группы и удалить конкретные вторичные копии, такую операцию лучше выполнять специализированным дубликат-менеджером либо вручную после анализа Info, сохраняя резервную копию.

Резервное копирование библиотеки

Защита PhotoStructure состоит из двух уровней: исходные медиа и служебная библиотека. Если automatic organization выключена, главным активом остаются фотографии и видео в scan paths. База и превью ускоряют восстановление, но не заменяют исходники. Если automatic organization включена, организованные копии становятся ещё одним набором оригинальных файлов и тоже должны входить в план резервного копирования.

Перед резервированием серверной библиотеки желательно остановить PhotoStructure или использовать способ, корректно работающий с открытой SQLite-базой. Простое копирование живой базы на уровне файловой системы может попасть в середину записи. Снимок файловой системы, согласованный backup или остановка процесса дают более предсказуемый результат.

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

Проверка восстановления важнее факта существования копии. Периодически полезно развернуть резерв базы и небольшой набор файлов в отдельной тестовой среде и убедиться, что библиотека открывается, теги читаются, а пути понятны. Это особенно важно после изменения Docker mounts или гибридной схемы с отдельным originals directory.

Что доступно в LITE и зачем учитывать PLUS

Базовый LITE даёт self-hosted библиотеку без ограничения количества фото и видео, дедупликацию и мобильный интерфейс. В актуальной ветке импорт метаданных Apple Photos также перенесён в LITE. Для знакомства с существующим архивом этого достаточно: можно проиндексировать коллекцию, оценить группировку дублей, навигацию и поиск.

PLUS нужен для части операций, которые меняют организацию и содержимое: automatic organization, валидация некоторых типов медиа, архивирование/исключение/удаление, извлечение ряда face tags по плану аккаунта и ручное редактирование тегов через Asset Info. Набор стоит проверять по текущему экрану лицензии, поскольку отдельные функции со временем переходят между планами.

Практический вывод: не стройте рабочий процесс на команде, которая доступна только в PLUS, не проверив лицензию конкретной установки. Особенно это касается Edit tags, automatic organization и операций удаления. При этом чтение уже существующих тегов и основная каталогизация не требуют превращать PhotoStructure в редактор метаданных.

Ограничения, которые важно знать заранее

Нет собственного распознавания лиц

Категория Who не означает, что PhotoStructure анализирует лица нейросетью. Она умеет использовать уже записанные face/person metadata и дополнять Who вручную по одному asset. Если главная цель — автоматически найти все лица в старом архиве и сгруппировать их по людям, понадобится другой инструмент.

Нет полноценного фоторедактора

PhotoStructure не заменяет RAW-конвертер или растровый редактор. Здесь нет привычного набора экспозиции, кривых, масок, удаления объектов, пластики, локальной цветокоррекции и слоёв. Программа организует, индексирует, показывает и в ограниченных случаях меняет метаданные. Художественная обработка остаётся за внешним приложением.

Ручная работа с тегами ориентирована на один asset

Редактор тегов полезен для точечных исправлений, но не является массовым DAM-интерфейсом. Альбомы также редактируются по одному asset. Если нужно за один раз присвоить сложную иерархию тысячам файлов, удобнее подготовить XMP во внешнем пакетном инструменте и затем синхронизировать PhotoStructure.

Встроенная аутентификация пока отсутствует

Сетевой интерфейс нельзя безопасно выставлять в интернет без дополнительного слоя. Для удалённого доступа требуется VPN или reverse proxy с HTTPS и аутентификацией. Сам параметр публикации в LAN не создаёт пользователей и пароль.

Логическая дедупликация не очищает диски автоматически

Скрытие повторов в галерее и физическое освобождение места — разные операции. PhotoStructure намеренно хранит уникальные варианты осторожно. Если главная задача — освободить терабайты, удалив побайтные и визуальные дубликаты по строгой политике, понадобится отдельный этап.

Крупный первый импорт требует времени и свободного места

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

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

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

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

ФотоМАСТЕР нужен, когда меняется сама картинка. В нём есть замена и размытие фона, удаление объектов, автоматическая портретная ретушь, «Пластика лица» и «Пластика фигуры», локальная коррекция, фильтры, работа с RAW и пакетная обработка. Пакетный режим применяет общие параметры улучшения, эффекты и другие допустимые операции к серии изображений.

PhotoStructure не конкурирует с этими функциями. Её задача — найти нужный кадр среди сотен тысяч файлов, понять, какие варианты относятся к одному снимку, прочитать теги и показать структуру архива. Логичный совместный процесс: PhotoStructure используется для поиска и навигации, внешний редактор — для пиксельной обработки, после сохранения метаданных или новой версии PhotoStructure выполняет sync.

Если требуется убрать человека с фона, выровнять кожу, заменить небо или подготовить десятки кадров с одной коррекцией, ФотоМАСТЕР соответствует задаче напрямую. Если проблема формулируется как «у меня пять дисков, несколько Takeout, RAW+JPEG и я не понимаю, где что лежит», это уже профиль PhotoStructure.

PhotoStructure и PhotoPrism

PhotoPrism также работает как self-hosted фотокаталог и умеет индексировать существующие файлы, показывать их через PWA, искать по множеству свойств и читать метаданные. Главное функциональное различие — встроенные AI-возможности: PhotoPrism автоматически классифицирует изображения, распознаёт лица и группирует их по людям. У него есть карты и географический интерфейс.

PhotoStructure делает ставку на уже существующие метаданные, файловую структуру и предсказуемые иерархические теги. Она не пытается автоматически назвать содержимое изображения или распознать человека. Поэтому пользователь, который годами вкладывался в XMP, папки, face regions и Takeout metadata, получает прозрачный слой над существующей системой. Пользователь, которому важнее автоматическая AI-классификация необработанной коллекции, увидит больше готовой семантики в PhotoPrism.

Обе системы требуют серверного мышления при удалённом доступе и больших библиотеках, но сетевые функции различаются. PhotoPrism предлагает собственные механизмы альбомов, sharing и более развитую географическую визуализацию; PhotoStructure текущего выпуска не имеет встроенной аутентификации и не позиционирует карту как основной способ навигации.

PhotoStructure и Immich

Immich проектируется как self-hosted сервис для повседневной жизни с телефонами. Официальные мобильные приложения автоматически отправляют выбранные альбомы на сервер, умеют фоновый backup, а сервер поддерживает нескольких пользователей, публичные ссылки, partner sharing, timeline, карты, альбомы и корзину.

Machine learning в Immich заметно шире: есть распознавание лиц, контекстный CLIP-поиск свободными фразами и OCR. Поиск работает не только по записанным тегам, но и по визуальному содержимому. Это удобно, когда метаданные бедны и пользователь хочет спросить систему о «закате на пляже», не размечая архив вручную.

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

Immich тоже поддерживает external libraries, но часть изменений для внешних assets хранится в базе Immich и не записывается обратно в исходные файлы. Для пользователей, которые считают XMP и переносимые metadata главным «источником истины», это архитектурное различие заслуживает отдельного внимания.

Как выбирать между PhotoStructure, PhotoPrism и Immich

Начните не с списка функций, а с происхождения архива. Если большая коллекция уже имеет продуманную папочную структуру, sidecar, camera metadata, face regions из внешней DAM и много файловых вариантов, PhotoStructure хорошо использует этот капитал. Если метаданные почти отсутствуют и нужна автоматическая классификация по содержимому, PhotoPrism даёт больше встроенного AI.

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

ФотоМАСТЕР находится в другой оси выбора: его имеет смысл сравнивать не по серверным функциям, а по необходимости редактировать изображения. Он может дополнять любую из трёх систем каталогизации.

Когда PhotoStructure особенно уместна

Программа хорошо подходит для архива, который нельзя «импортировать и забыть» в одной новой структуре. Если существуют рабочие оригиналы, резервные копии, внешние диски, сетевые шары, Google Takeout, Apple Photos и многолетние XMP, PhotoStructure способна построить единый индекс поверх них, не требуя немедленно разрушать прежнюю организацию.

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

Третий сценарий — пользователь, которому важны переносимые метаданные. PhotoStructure читает и в ряде случаев пишет XMP/совместимые поля, умеет использовать метаданные Apple Photos и Google Takeout и не требует скрывать всю смысловую информацию только в собственной базе.

Когда лучше выбрать другой инструмент

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

Если необходимо автоматически распознать сотни тысяч лиц без предварительной разметки, используйте систему с собственным face-recognition. PhotoStructure сможет прочитать результаты, если они будут сохранены в совместимой форме, но сама этот анализ не выполняет.

Если приоритет — резервирование камеры смартфона сразу на домашний сервер, отдельные семейные аккаунты и публичный sharing, специализированный self-hosted сервис вроде Immich закрывает больше задач из коробки. PhotoStructure в таком окружении может оставаться вторичным каталогизатором существующей файловой системы.

Если единственная цель — найти и физически удалить дубли ради освобождения диска, специализированный duplicate cleaner проще. PhotoStructure сознательно избегает агрессивного удаления вариантов, потому что различающиеся файлы одного кадра могут иметь самостоятельную ценность.

Рабочая схема для долгосрочной фототеки

Устойчивый процесс начинается с определения «источника истины». Выберите каталоги, где хранятся мастер-файлы и их метаданные. Остальные копии рассматривайте как резервные, производные или импортные. PhotoStructure индексирует все источники, но не должна быть поводом редактировать один и тот же metadata-набор независимо в пяти местах.

Второй слой — резервирование. До включения автоматической организации и особенно до операций Delete убедитесь, что есть независимая копия. Организованная PhotoStructure-копия может быть частью стратегии, но не единственной резервной копией на том же физическом диске.

Третий слой — семантика. Оставьте When, Camera, Lens и filesystem автоматике, а ручную разметку сосредоточьте на тех категориях, которые невозможно надёжно вывести автоматически: люди без face metadata, события, темы, отборы и редкие контекстные ключевые слова.

Четвёртый слой — обслуживание. Просматривайте System activity после крупных импортов, держите свободное место, не оставляйте debug logging включённым и проверяйте Health. После внешнего изменения метаданных используйте точечный sync вместо постоянных rebuild.

Контрольный список перед большим импортом

• Определить, где будут база, превью и при необходимости organized originals.
• Проверить свободное место с запасом на превью и транскодированные видео.
• Смонтировать NAS и внешние диски по устойчивым путям.
• Проверить права чтения источников и записи библиотеки.
• Решить, нужна ли automatic organization или пока достаточно индекса.
• Проверить небольшой набор RAW, JPEG, HEIC, видео и XMP.
• Убедиться, что FFmpeg/HEIF support исправны, если эти форматы используются.
• Выбрать разумный duplicate matching и проверить серию похожих кадров.
• Проверить импорт Keywords, Who, Albums и Where на нескольких известных файлах.
• Настроить резервное копирование до команд удаления.
• Для сетевого доступа подготовить VPN или аутентифицирующий reverse proxy.

После первого успешного импорта

Не спешите сразу усложнять конфигурацию. Несколько дней поработайте с обычным поиском, When, filesystem и Info, отметьте повторяющиеся неудобства и только затем меняйте правила. Если чаще всего мешают ложные совпадения, корректируйте duplicate matching; если трудно находить смысловые группы, дорабатывайте Keywords, Event или Albums; если тормозит удалённый просмотр, сначала измерьте, где находятся база и превью. Такой порядок связывает каждую настройку с наблюдаемой проблемой. Перед крупным изменением сохраните settings.toml и резервную копию базы, а после изменения обработайте тестовый фрагмент библиотеки. Это проще, чем откатывать массовую перестройку, когда одновременно были изменены пути, профиль превью, правила дат и дедупликация.

Итог

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

Наиболее важные особенности программы одновременно являются её ограничениями. Дедупликация ориентирована на удобное представление, а не на агрессивную физическую чистку. Who зависит от уже существующих face/person metadata и не содержит собственного распознавания лиц. Редактирование тегов работает точечно, а художественной обработки изображения нет. Сетевой интерфейс требует внешней защиты, если выходит за пределы доверенной сети.

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