En mi búsqueda de una aplicación de administración de fotos perfecta (lo sé :), he estado haciendo un poco de comparación entre las pocas aplicaciones que me parecen atractivas en cuanto a características/costo. Una de las diferencias más importantes es que algunas aplicaciones guardan metadatos en las imágenes (sobrescribiendo los originales de alguna manera) y otras los guardan en sus bases de datos.
Aunque prefiero mantener los originales siempre intactos, puedo ver cómo el enfoque de tener todos los metadatos con la imagen en sí podría resultar beneficioso.
¿Existen ventajas/desventajas no obvias para un enfoque u otro, y lo que generalmente se considera la mejor práctica (consciente de que esto es algo subjetivo, así que si pudiera dar una razón o dos)?
Si al menos alguna información de catalogación está escrita en la imagen, entonces puede volver a conectar un archivo a su base de datos. En principio, esto puede ser una única identificación única.
Esto te salva de:
Si puede escribir más información en el archivo (palabras clave, subtítulos), entonces se salva de:
Una tercera opción es escribir metadatos en archivos sidecar. Normalmente, estos archivos tienen el mismo nombre que el archivo principal, pero un sufijo diferente.
Escribir en los archivos originales puede dañar el archivo. La mayoría de los formatos RAW ahora se entienden lo suficientemente bien como para al menos identificar y reemplazar cadenas de metadatos con cadenas de la misma longitud. Si le dices a tu cámara que ponga la cadena de derechos de autor
Copyright 2018 J. Random Shutterbug Image XXXX-XXXX-XXXX-XXXX-XXXX-XXXX
Entonces, mientras el DAM mantenga esa cuerda de la misma longitud, eres dorado.
Mantener todos los metadatos (o la mayor cantidad posible) en las imágenes originales hace que el acceso sea muy lento. Su programa tiene que leer al menos los primeros bloques de cada imagen.
La reescritura de datos lleva mucho tiempo.
Algunos formatos de archivo no tienen ninguna capacidad de metadatos.
Algunos formatos de archivo (Photoshop PSD) son conocidos por alterar los metadatos.
Una falla durante el proceso de escritura puede dañar el archivo de imagen. La alternativa, escribir un archivo nuevo y luego reemplazar el archivo anterior, requiere que se lea y escriba todo el archivo, en lugar de solo una parte. Esto tiene serios problemas de rendimiento.
Las bases de datos son rápidas, pero tienen borrones, y estás escribiendo en medio de borrones de datos. Si la implementación de la base de datos es sólida, no hay mucho de qué preocuparse. Pero los discos duros tienen errores, y un solo error puede hacer que una base de datos quede parcial o totalmente inutilizable. Un buen diseño de base de datos tiene redundancia incorporada para que pueda reparar/reconstruir.
Las bases de datos son frecuentemente propietarias. Los datos pueden comprimirse para aumentar la velocidad. Obtener sus datos puede ser complicado. (Problema para las personas que usan la apertura)
Las bases de datos con frecuencia se optimizan de diferentes maneras. En general, la robustez se gana a costa del rendimiento y la complejidad. Un compromiso es escribir todos los cambios primero en un archivo de transacción (rápido...) y luego un proceso en segundo plano actualiza la base de datos en segundo plano.
Tienes que leer un trillón de archivos al inicio.
Si realiza un cambio por lotes (agregue la palabra clave "Italia" a las 3000 fotos de su viaje de vacaciones de verano), el programa de catálogo ha abierto, modificado y vuelto a escribir 3000 archivos.
Si cambia el nombre de un archivo y no cambia el nombre del archivo sidecar también, sus metadatos ya no están conectados a su imagen.
Opinión solo aquí: Lo siento.
Si la base de datos falla, se puede reconstruir desde los sidecars.
Si un sidecar está dañado, se puede reconstruir a partir de la base de datos.
Si se cambia el nombre de una imagen, la ID se puede usar para volver a conectarla al sidecar y para reparar la base de datos.
Para que esto funcione, debe usar muchas marcas de tiempo. Si el sidecar es más reciente que la última marca de tiempo en el registro de la base de datos, entonces el sidecar es el registro autorizado.
Dada la naturaleza relativamente frágil de los archivos sin formato, la mejor práctica es un sistema que solo escribe cero o una vez en el archivo sin formato. el archivo exif
No es necesario actualizar los sidecars en tiempo real. La forma ingeniosa de hacer esto sería que cada vez que la base de datos haga un cambio en un registro:
Esto no está completo: no aborda el problema de las ediciones no destructivas. Muchos programas ahora permiten la creación de varias imágenes a partir del mismo archivo maestro y no crean un mapa de bits nuevo, sino un archivo con una serie de instrucciones sobre cómo crear la imagen a partir del maestro. AFAIK todos esos métodos son propietarios. Esto da como resultado un dilema, ya que las aplicaciones que hacen un buen trabajo de seguimiento de los metadatos pueden no ser capaces de lidiar con las ediciones no destructivas. Esto puede ser crítico si recorta a una persona de una imagen.
La solución es que siempre escriba una nueva imagen de mapa de bits de una edición seria. Idealmente, tiene una secuencia de comandos que busca nuevas ECM y escribe una imagen basada en esto, copiando los metadatos del maestro y en algún momento llevándolo a revisión para modificar los metadatos.
Esto parece ser algo muy polarizador. Si bien nunca elegiría un software que modifique mis imágenes de ninguna manera, ¡conozco personas que no elegirían uno que no almacene los metadatos en archivos!
El problema es que si los metadatos son externos, los archivos no se tocan. En mi sistema, las imágenes están montadas en una partición de solo lectura, por lo que garantizo que ningún software puede cambiarlas, lo que tiene algunas ventajas que son importantes para mí :
La ventaja citada de tener metadatos en el archivo es que estos dos no se pueden separar y siempre viajan juntos al copiar o mover archivos.
Un gran problema con el almacenamiento de metadatos en imágenes es que los formatos como JPEG EXIF tienen metadatos patentados, llamados "makernotes" producidos por los fabricantes de cámaras, editar cualquier dato EXIF puede resultar en la pérdida completa de los metadatos propietarios.
Por ejemplo, el uso de versiones recientes de Picasa para asignar un título a una imagen da como resultado la pérdida de todos los datos de propiedad de Nikon sobre la lente utilizada y la configuración de la cámara (compensación de exposición utilizada, etc.). Las versiones anteriores de Picasa no tenían este problema (probablemente usaron una base de código diferente para esta función). Este es un ejemplo de cómo un flujo de trabajo que parece funcionar ahora puede tener consecuencias altamente indeseables en una versión posterior del software que utiliza.
Si selecciona cuidadosamente una solución DAM correcta que no dañe sus metadatos existentes mientras actualiza sus imágenes (como dijo RedGrittyBrick), tendrá más beneficios al guardar sus metadatos en imágenes:
Por supuesto, lo dicho anteriormente es cierto si su solución DAM es un producto maduro con un seguimiento comprobado de clientes, y sus metadatos se escribirán correctamente en las imágenes de acuerdo con la especificación XMP/MWG.
Y, por supuesto, necesita hacer una copia de seguridad de sus imágenes originales y organizar copias de seguridad automáticas y diarias de su base de datos.
Evite las soluciones DAM con los siguientes problemas:
Torre