Существует ли известный способ хранения иерархии таксономии в XMP, IPTC или EXIF?

У клиента есть банк изображений с большим количеством изображений. Они классифицировали эти изображения в иерархии. Теперь они хотят переместить изображения в новый банк изображений, и меня просят поместить эту иерархию в данные EXIF ​​или XMP внутри изображений. Технически, используя exiftool, это очень просто, но я не могу найти никаких соглашений о том, какое поле использовать и как. Итак, кто знает, как хранить такие иерархические данные в EXIF?

Ответы (4)

Итак, немного покопавшись и с помощью подсказки Мурата я нашел на некоторых картинках следующее поле. По сути, это способ, которым Adobe Lightroom хранит информацию, и его можно использовать в качестве стандарта де-факто в вашем проекте. Мы уже использовали подобное решение с нашим собственным именем поля и без использования rdf, но чтобы закрыть этот вопрос, вот решение Lightroom, экспортированное exiftool:

 <XMP-lr:HierarchicalSubject>
   <rdf:Bag>
     <rdf:li>general|mission|ISAF</rdf:li>
     <rdf:li>Army|vehicle|Fennek</rdf:li>
     <rdf:li>Army|personnel|troops</rdf:li>
     <rdf:li>general|mission</rdf:li>
     <rdf:li>Army</rdf:li>
   </rdf:Bag>
 </XMP-lr:HierarchicalSubject>

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

Например, digiKam использует TagsListимя поля в метаданных XMP для хранения своей иерархии тегов. Поэтому, когда я помечаю изображение вложенным тегом «Брайтон», который вложен в вложенный тег «Восточный Суссекс», вложенный в вложенный тег «Великобритания», вложенный в тег верхнего уровня «расположенный», и а также вложенный тег «Друзья», вложенный в «заполненный» тег верхнего уровня, digiKam добавляет его в поле «Список тегов»:

populated/Friends, located/UK/East-Sussex/Brighton

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

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

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

Я ИТ-консультант, специализирующийся на миграции. Ваше решение подходит для небольших наборов или даже для больших, если вы используете их по отдельности. Проблема в том, что нет централизованного способа администрирования вашей иерархии, и если вы захотите переместить один тег на другой уровень или реорганизовать ветвь, вам придется снова редактировать каждое отдельное поле. Итак, что я действительно хочу знать: нет ли лучшего стандартизированного способа сделать это? Если нет, мы можем в конечном итоге сделать это, как вы предлагаете, используя ботов для пометки.
Единственным способом централизованного управления иерархической структурой было бы использование системы баз данных, которая поддерживает структуры в одной таблице, чтобы иерархическую структуру можно было легко реорганизовать. Но это не то, как работают метаданные в файлах изображений, потому что каждый файл изображения существует сам по себе. Если вы измените способ структурирования иерархии, вам придется обновлять метаданные в каждом файле изображения один за другим. Использование дополнительных файлов XMP сократит время, необходимое для таких обновлений, но в этом случае вы рискуете отделить файл изображения от файла его метаданных.
Риск разделения метаданных из изображения уравновешивается безопасностью, заключающейся в том, что никогда не нужно записывать в файл изображения, поэтому его не так легко вырезать и высушить, если файлы имеют уникальные имена, то их сопоставление было бы легко, если бы вам пришлось .
Я имел в виду, что действительно следует использовать базу данных, а затем хранить, например, идентификаторы категорий в изображениях. В любом случае основной вопрос моего вопроса остается, а именно: неужели для этого вообще нет стандарта? Меня бы это скорее удивило.
Нет - стандарта нет. Это никогда не считалось необходимым, поскольку любая организация или поиск обычно выполнялись с помощью ключевых слов. Также стоит хранить полные метаданные в/с файлом, потому что таким образом он сохраняет метаданные, если вам нужно предоставить их третьей стороне. Проблема с базой данных уже решена, если вы используете Windows, поскольку служба сервера индексирования считывает и кэширует метаданные из файлов.

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

EXIF в основном используется для хранения технической информации о камере и съемке изображений.

Другим стандартом является IPTC, но он устарел и имеет значительные ограничения на длину полей.

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

Самый популярный подход — хранить иерархические данные внутри вашего XMP (MWG), разделяя каждый уровень символом «|». разделитель. Эти символы используются во многих решениях DAM (неофициально), включая Daminion, Lightroom, IdImager, MS Photogallery, iView/MediaPro и т. д.

Так что не изобретайте велосипед и подумайте о хорошем решении DAM!

Спасибо за указание на XMP/MWG, посмотрю на это. Это для правительства, они решили построить свою собственную дамбу...
Честно говоря, это было бы последним, что я сделал бы, если бы работал на правительство. Они должны представить, что DAM — это не один решатель задач, это комбайн с множеством функций, которые должны быть спроектированы, реализованы и работать вместе. Доступное решение DAM стоит за сотнями медиаформатов и десятками спецификаций метаданных и сотнями тысяч часов разработки (в долларах). Мы в Daminion Team занимаемся этой задачей с 2003 года, и у нас есть много вещей, которые мы планируем сделать. Просто некоторые мысли.

Таксономия? Exiftool уже некоторое время поддерживает запись Darwin Core как XMP.

http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/DarwinCore.html

http://rs.tdwg.org/dwc/terms/

Resource Space — это бесплатное программное обеспечение DAM, которое использует exiftool в качестве серверной части метаданных. Вы можете настроить его для поддержки Darwin Core.