Wanderer (lair) wrote,
Wanderer
lair

  • Music:

Фотоархив: стратегии и оптимизация архивных копий

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

Я буду рад, если все, кто сколько-нибудь в теме, выскажут свое мнение.

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

  • копирование данных со внешнего носителя (карточки или диска), с автоматическим созданием локальной структуры каталогов и переименования файлов по заданному закону (например, по дате/времени)
  • разбор съемки
  • обработка выбранных кадров
  • предпечатная подготовка и подготовка к публикации в Web
  • возможность при последующем обращении легко найти фотографию по заданным критериям (каталогизация)
  • создание архивных копий фотографий и метаинформации
  • перенос старых фотографий в архив с удалением из основной базы и сохранением возможности поиска (offline copy)

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

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

Второй очевидный вариант состоит в том, чтобы архивировать приходящие данные (иными словами, содержимое внешнего носителя) и результаты работы. В этом случае мы снимаем две первых проблемы (потерю данных во время работы над съемкой), но приобретаем взамен другую: содержимое внешнего носителя обладает неформализованной нами структурой, таким образом, соотнести эти данные с тем, что находится в нашей локальной структуре может оказаться сложно (если, конечно, не хранить в метаданных еще и адрес оригинала). Третья (неявная) проблема остается, как и была: после окончания работы над съемкой и создания архивной копии, при возвращении к работе создание новой архивной копии не формализуемо.

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

Заметим сразу, что решение второй половины проблемы (архивная копия результатов работы) решается, при условии хранения всего в обычной файловой системе, любым хорошим менеджером архивных копий — по сути, мы имеем дело с классическим сценарием полного/частичного резервирования. Да и первая часть им решается, если подумать, вопрос лишь организации процесса.

Об этой организации, собственно, и речь. Предположим, мы используем для всей нашей работы Lightroom — тогда после скачивания файлов с носителя нам понадобится закрыть (для надежности) Lightroom, сформировать резервную копию, вернуться к работе. Не архиудобно. Альтернатива — использовать стороннюю программу навроде Downloader Pro (которая, к несчастью, еще и удобнее в этом отношении, нежели Lightroom), но тогда, во-первых, рабочая цепочка увеличится на одну программу (что плохо), во-вторых, после этого придется проводить импорт в Lightroom, что есть дополнительное время (чего хочется избежать), да и может приводить к модификации файлов, что тоже не подарок (для системы резервирования).

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

А вот теперь ключевой вопрос: где я ошибся? И где можно сделать удобнее?

Tags: photo
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 5 comments