¿Hay alguna forma conocida de almacenar una jerarquía de taxonomía en XMP, IPTC o EXIF?

Un cliente tiene un banco de imágenes con muchas fotografías. Han categorizado esas imágenes en una jerarquía. Ahora quieren mover las imágenes a un nuevo banco de imágenes y me piden que coloque esta jerarquía en los datos EXIF ​​o XMP dentro de las imágenes. Técnicamente, usar exiftool es muy fácil, pero parece que no puedo encontrar ninguna convención sobre qué campo usar y cómo. Entonces, ¿quién sabe cómo almacenar este tipo de datos jerárquicos en EXIF?

Respuestas (4)

Entonces, después de investigar un poco y con la ayuda de la pista de Murat, encontré el siguiente campo en algunas imágenes. Básicamente, esta es la forma en que Adobe Lightroom almacena la información y podría usarse como un estándar de facto en su proyecto. Ya buscamos una solución similar con nuestro propio nombre de campo y sin uso de rdf, pero solo para cerrar esta pregunta, aquí está la solución de Lightroom exportada por 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>

Bueno, puede encontrar una lista de nombres de campos XMP utilizados por el software fotográfico común en esta página .

Por ejemplo, digiKam usa el TagsListnombre del campo en los metadatos XMP para almacenar su jerarquía de etiquetas. Entonces, cuando marco una imagen con la subetiqueta "Brighton" que está anidada debajo de la subetiqueta "East-Sussex", anidada debajo de la subetiqueta "UK", anidada debajo de la etiqueta de nivel superior "ubicado" y también la subetiqueta "Amigos" anidada debajo de la etiqueta de nivel superior "poblada", digiKam agrega esto al campo TagsList:

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

Este formato prohíbe que los valores de etiquetas individuales contengan espacios o barras diagonales, pero creo que las etiquetas deben ser tokens compactos y únicos con un significado definido, no texto libre detallado, por lo que esta restricción no debería ser un problema.

Para ser honesto, no debería importar cómo elija almacenar la información siempre que funcione para usted en ese momento y siempre que documente sus decisiones para que los futuros usuarios puedan migrar los metadatos a un nuevo formato en el futuro si es necesario. surge

Yo diría que es más importante que elijas un formato y luego lo mantengas de manera consistente. Los datos coherentes se pueden traducir y migrar automáticamente de un formato a otro. Los datos inconsistentes son basura que requiere horas de intervención humana cada vez que deben procesarse. (Y debería saber: por lo general, parece que soy yo quien termina teniendo que procesarlo).

Soy Consultor TI especializado en migraciones. Su solución está bien para conjuntos pequeños, o incluso más grandes si los usa solos. El problema es que no existe una forma central de administrar su jerarquía, si quisiera mover una etiqueta a otro nivel o reorganizar una rama, terminaría editando cada campo por separado nuevamente. Entonces, lo que realmente quiero saber es: ¿no hay una mejor forma estandarizada de hacer esto? Si no lo hay, podríamos terminar haciéndolo como sugieres, usando bots para hacer el etiquetado.
La única forma de tener una estructura jerárquica administrada centralmente sería usar un sistema de base de datos que mantenga las estructuras en una sola tabla, de modo que la estructura jerárquica pueda reorganizarse con facilidad. Pero no es así como funcionan los metadatos en los archivos de imagen, porque cada archivo de imagen es independiente. Si cambia la forma en que desea estructurar la jerarquía, debe actualizar los metadatos en cada archivo de imagen uno tras otro. El uso de archivos sidecar XMP reducirá el tiempo necesario para realizar tales actualizaciones, pero luego corre el riesgo de separar el archivo de imagen de su archivo de metadatos.
El riesgo de dividir los metadatos de la imagen se equilibra con la seguridad de no tener que escribir nunca en el archivo de imagen, por lo que no es tan fácil de cortar y secar, si los archivos tienen nombres únicos, sería fácil emparejarlos si tuviera que hacerlo. .
Quise decir que uno debería usar una base de datos y luego almacenar, por ejemplo, identificaciones de categoría en las imágenes. De todos modos, el punto principal de mi pregunta sigue siendo, a saber: ¿no hay ningún estándar para esto? Eso me sorprendería bastante.
No, no hay un estándar. Uno nunca se consideró necesario ya que cualquier tipo de organización o búsqueda se realiza y generalmente se realiza a través de palabras clave. También vale la pena mantener los metadatos completos en/con el archivo porque de esa manera conserva los metadatos si necesita proporcionarlos a un tercero. El lado de la base de datos ya es un problema resuelto si usa Windows, ya que el servicio del servidor de indexación lee y almacena en caché los metadatos de los archivos.

Puedes sugerirle a tu cliente que utilice un Digital Asset Management para administrar su banco de imágenes. Las soluciones DAM más modernas pueden guardar automáticamente la jerarquía de etiquetas en XMP.

EXIF se utiliza principalmente para almacenar información técnica de captura de imágenes y cámaras.

Otro estándar es IPTC pero está obsoleto y tiene limitaciones significativas en la longitud de los campos.

La información jerárquica es compatible con la especificación XMP/MWG, pero conozco muy pocos programas que la admitan bien.

El enfoque más popular es almacenar datos jerárquicos dentro de su XMP (MWG) separando cada nivel con el "|" separador. Este símbolo es utilizado por muchas soluciones DAM (extraoficialmente), incluyendo Daminion, Lightroom, IdImager, MS Photogallery, iView/MediaPro, etc...

¡Así que no reinvente una rueda y considere una buena solución DAM!

Gracias por el puntero a XMP/MWG, lo investigaré. Es para un gobierno, decidieron construir su propia DAM...
Para ser honesto, sería lo último que haría si trabajara para un gobierno. Deben imaginar que DAM no es un solucionador de una sola tarea, es una combinación con muchas características que deben diseñarse, implementarse y trabajarse juntas. Hay cientos de formatos de medios y docenas de especificaciones de metadatos y cientos de miles de horas de desarrollador (ver dólares) detrás de una solución DAM asequible. En Daminion Team estamos involucrados en esta tarea desde 2003 y hay muchas cosas que planeamos hacer. Solo algunos pensamientos.

¿Taxonomía? Exiftool admite escribir Darwin Core como XMP desde hace un tiempo.

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

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

Resource Space es un DAM de software gratuito que utiliza exiftool como backend de metadatos. Puede personalizarlo para admitir Darwin Core.