Сохранение метаданных в изображениях и во внешней базе данных

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

Это избавит вас от:

• Вы переместили или переименовали файл изображения.

Если вы можете написать в файл больше информации — ключевые слова, подписи — тогда вы спасены от:

• Ваша база данных повреждена.
• Вы обновили свой компьютер, и ваша программа базы данных там не работает.

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

• Это позволяет восстановить все ваши данные в случае сбоя базы данных.

Недостатки хранения данных в образе:

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

Copyright 2018 J. Random Shutterbug Image XXXX-XXXX-XXXX-XXXX-XXXX-XXXX  

Затем, пока DAM сохраняет эту строку той же длины, вы являетесь золотым.

Сохранение всех метаданных (или всего, что вы можете) в исходных изображениях делает доступ к ним очень медленным. Ваша программа должна прочитать хотя бы несколько первых блоков каждого изображения.

• Запись данных назад занимает много времени.

• Некоторые форматы файлов не поддерживают метаданные.

• Некоторые форматы файлов (Photoshop PSD) отличаются искажением метаданных.

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

Недостатки баз данных

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

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

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

Недостатки колясок

Вы должны прочитать миллионы файлов при запуске.

Если вы сделаете пакетное изменение (добавите ключевое слово «Италия» ко всем 3000 снимков ваших летних каникул), программа каталога откроет, модифицирует и запишет 3000 файлов.

Если вы переименуете файл и не переименуете файл сопроводительного файла, ваши метаданные больше не будут связаны с вашим изображением.

Лучшая практика

Мнение только здесь: Извините.

• Вам нужен уникальный тег актива, который находится на изображении. Это может быть фактический тег, такой как авторское право, упомянутый выше, или тег, производный от информации в изображении. Это может быть отметка времени EXIF ​​(не уникальная — несколько снимков в секунду, несколько камер). Если ваша программа читает заметки производителя, лучше всего выбрать модель камеры + серийный номер камеры + отметку времени + сотые доли секунды.
• Вам нужна база данных для скорости. Он, конечно, имеет уникальный идентификатор
• Вам нужны дополнительные компоненты для восстановления базы данных и переносимости данных. У них уникальный идентификатор.

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

Если sidecar поврежден, его можно восстановить из базы данных.

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

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

Учитывая относительно хрупкую природу необработанных файлов, наилучшей практикой является система, которая записывает только ноль или один раз в необработанный файл. Exif

Коляски не нужно обновлять в режиме реального времени. Удобным способом сделать это было бы то, что всякий раз, когда база данных вносит изменения в запись:

• Создайте новую запись, дублирующую старую запись в базе данных.
• Внесите изменения в новую запись.
• Новая запись помечена как "не записана в коляску"
• Старая запись помечена как "устаревшая"
• Другой поток записывает файлы sidecar, записывает новый, затем удаляет старый (или переименовывает новый в имя старого).
• Периодически вы запускаете очистку базы данных, удаляя устаревшие записи старше X дней. Это дает вам возможность откатить изменения.

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

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

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

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

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

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

Большая проблема с хранением метаданных в изображениях заключается в том, что такие форматы, как JPEG EXIF, имеют проприетарные метаданные, называемые «заметками производителя», созданные производителями камер, редактирование любых данных EXIF ​​может привести к полной потере проприетарных метаданных.

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

Если вы тщательно выберете правильное решение DAM, которое не повредит ваши существующие метаданные при обновлении ваших изображений (как сказал RedGrittyBrick), у вас будет больше преимуществ при сохранении ваших метаданных в изображения:

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

Конечно, сказанное выше верно, если ваше решение DAM является зрелым продуктом с проверенным временем клиентов, и ваши метаданные будут правильно записаны в образы в соответствии со спецификацией XMP/MWG.

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

Избегайте решений DAM при следующих проблемах:

• Ограниченная поддержка стандартов метаданных. Случайная поддержка метаданных XMP или Native Format.
• Неправильно написанные метаданные, которые невозможно прочитать так, как они были записаны. Например, очень немногие продукты могут правильно сохранять/читать иерархические ключевые слова и разбивать местоположение на Регион\Страна\Штат\Город\Местоположение в соответствии со спецификациями IPTC\XMP\MWG.
• Ограниченный успех в написании метаданных для различных форматов, включая Camera RAW, PNG или PDF.