Lo más importante
- 1Antes de la subida, el navegador reduce cada foto a un lado largo de 2000 píxeles como JPEG; en el proceso se pierden todos los datos EXIF. Por eso DIAVAG lee antes el momento de la toma en la cabecera del archivo y lo envía por separado.
- 2Se leen exactamente dos etiquetas del estándar Exif: DateTimeOriginal y, si existe, OffsetTimeOriginal con la zona horaria. Si falta el momento, el campo queda vacío y en el PDF no aparece deliberadamente ninguna fecha bajo la foto en lugar del momento de la subida.
- 3El servidor comprueba cada momento contra una ventana: más de 24 horas en el futuro o más de 10 años de antigüedad se descarta. La ubicación es la posición del dispositivo que sube las fotos en el momento de la subida, solo con permiso, no el dato GPS de la foto.
- 4Lo que la plataforma guarda es una copia reducida con dos metadatos probatorios, no el original. Para una prueba posterior, el archivo original debe conservarse en el dispositivo de captura o en una copia de seguridad propia.
Las fotos del smartphone llevan metadatos valiosos para un informe, sobre todo el momento de la toma. Pero esos metadatos no sobreviven por sí solos al camino hacia una plataforma. En cuanto una imagen se reduce en el navegador, todo el bloque de metadatos desaparece. Este artículo describe cómo DIAVAG afronta ese hecho: qué dos datos se aseguran antes de reducir, qué límites aplica el servidor, qué llega al PDF y qué, deliberadamente, no se afirma.
Por qué los metadatos no sobreviven a la subida
Una foto del smartphone suele ser mucho mayor de lo que necesita ser para un PDF de informe o un portal de clientes. Para la subida, DIAVAG reduce por ello cada imagen en el navegador antes de que llegue a la plataforma: a un lado largo de 2000 píxeles, codificada como JPEG con un nivel de calidad de 0,82. Las imágenes en formato JPEG o PNG que de todos modos no superan los 600 kilobytes se dejan intactas; las capturas HEIC del iPhone y los archivos WebP se convierten siempre, porque ahí la conversión de formato es el verdadero objetivo.
Esta reducción tiene un efecto secundario decisivo para el aseguramiento de pruebas: la imagen se carga en un lienzo y se recodifica desde ahí, y en ese proceso se pierden todos los datos EXIF. Al servidor llega una imagen sin metadatos. El único momento que el servidor conoce entonces por sí mismo es el de la subida, y ese es falso como momento de la toma en cuanto el perito sube las fotos al día siguiente.
La orientación es el único valor de metadatos que al reducir no se pierde, sino que se aplica: la imagen se gira antes de dibujarla tal como la cámara lo anotó en los datos EXIF, y después queda derecha. Todo lo demás – modelo de cámara, objetivo, exposición, coordenadas GPS incrustadas, notas del fabricante y miniaturas – ya no forma parte del archivo tras la reducción.
Dos etiquetas, leídas antes de tocar la imagen
Como los metadatos no sobreviven a la subida, DIAVAG lee el momento de la toma en el archivo intacto antes de reducirlo. El estándar Exif, que la Camera & Imaging Products Association mantiene como CIPA DC-008, en su versión más reciente Exif Version 3.1 con una traducción publicada el 30 de enero de 2026, define para ello una etiqueta llamada DateTimeOriginal. Contiene el momento de la toma como cadena en el formato «AAAA:MM:DD HH:MM:SS», con dos puntos también en la parte de la fecha. Una segunda etiqueta, OffsetTimeOriginal, indica la zona horaria de la toma, por ejemplo «+02:00».
Se leen exactamente esas dos etiquetas, nada más. El lector es deliberadamente pequeño: lee solo el inicio del archivo, 256 kilobytes, donde en JPEG el segmento con los datos EXIF está justo detrás del comienzo del archivo y que cubren también la cabecera de un archivo HEIC. Una biblioteca que trajera cientos de etiquetas, notas del fabricante y otros formatos de metadatos estaría fuera de toda proporción con los dos campos que realmente se necesitan. DateTimeOriginal no está en el primer directorio del archivo, sino en un subdirectorio al que apunta un puntero; el lector sigue ese puntero y busca allí las dos etiquetas.
El resultado se envía como momento en un formato inequívoco junto con el archivo reducido, exactamente una entrada por archivo en el mismo orden, para que el servidor pueda asociar ambos. Si un archivo no lleva un momento utilizable, porque es una captura de pantalla, un PNG, una imagen ya limpiada o procesada, se envía una entrada vacía. Una foto sin fecha legible no es motivo para que la subida falle.
La zona horaria y el marcador 0000:00:00
Dos particularidades del formato Exif exigen una decisión. La primera afecta a la zona horaria. DateTimeOriginal no la lleva. Si la cámara escribe además OffsetTimeOriginal, cosa que hacen muchos smartphones y cámaras actuales, el momento es inequívoco y se fija a través de él. Si falta la indicación, DIAVAG lee la hora como hora local del dispositivo que sube las fotos. Es la suposición mínima posible en este flujo: toma y subida ocurren en el mismo lugar, el perito junto al vehículo o el cliente con su teléfono. La alternativa, leer la hora como tiempo universal, se desviaría en Alemania siempre entre una y dos horas.
La segunda particularidad es el marcador. Los bloques EXIF vacíos contienen con frecuencia la indicación «0000:00:00 00:00:00». Un analizador de fechas ingenuo sigue calculando en silencio con esos campos y llegaría a una fecha del año 1899. DIAVAG comprueba por ello, tras la conversión, si salieron exactamente los campos que figuraban en la cadena; si no es así, el archivo se considera sin momento de la toma.
Ambas decisiones deben hacerse constar en el informe cuando importe. Un momento procedente de DateTimeOriginal sin zona horaria es una indicación de hora local bajo la suposición de que el dispositivo que subió las fotos estaba en la misma zona horaria que la cámara. En la inmensa mayoría de los encargos es el mismo dispositivo. Donde no sea así, por ejemplo con fotos que un cliente envía desde el extranjero, la reserva debe figurar en el texto.
La ventana de plausibilidad en el servidor
El momento de la toma llega al servidor como una indicación no verificada del cliente. Por eso se comprueba su plausibilidad allí, no en el navegador, porque los límites deben estar donde se acepta la indicación. Rigen dos límites. Hacia delante: un momento que esté más de 24 horas en el futuro se descarta; los relojes de los dispositivos van mal y en EXIF faltan las zonas horarias, por eso la tolerancia es generosa pero finita. Hacia atrás: todo lo que tenga más de 10 años se descarta igualmente, porque ese valor es por experiencia un marcador o un reloj averiado, no una foto probatoria de un encargo en curso.
Si un momento queda fuera de la ventana o falta, el campo queda vacío. La plataforma no pone en su lugar el momento de la subida. Ese se guarda por separado, como momento en que llegó el archivo, y es rastreable como tal en cualquier momento. En el PDF, bajo una foto sin momento de la toma no aparece deliberadamente ninguna fecha. Una fecha ausente es una indicación honesta; una fecha de subida presentada como fecha de la toma sería una falsa.
La misma regla rige en ambas vías de subida. Las fotos que el perito sube en la captura y las fotos que un cliente entrega él mismo a través del enlace previo sin iniciar sesión pasan por la misma ventana con los mismos límites; ambas vías deben decidir de forma idéntica, si no la misma foto tendría una fecha distinta según el remitente. Por encargo son posibles en total 40 fotos, de ellas como máximo 12 a través del enlace del cliente. Una imagen que se ha marcado en el editor de fotos y se ha guardado como archivo nuevo no lleva momento de la toma; la marca es una edición, y la fecha de la edición no es la fecha de la toma.
La ubicación: el dispositivo al subir, no la foto
El segundo metadato probatorio es la ubicación, y aquí la precisión en la descripción importa más que la propia coordenada. DIAVAG no guarda el dato GPS de la foto. Ese se perdería de todos modos tras la reducción, y tampoco se lee antes. Se guarda la posición del dispositivo que sube las fotos en el momento de la subida, consultada a través de la función de ubicación del navegador, sin alta precisión y con una espera de como máximo cinco segundos. Si el usuario no concede el permiso o el dispositivo no responde a tiempo, no se guarda ninguna ubicación.
En el servidor, la coordenada se comprueba contra su rango de valores y en caso contrario se descarta. En el PDF aparece en el pie de foto junto con el momento de la toma, con cinco decimales. Lo que la coordenada prueba queda así claramente delimitado: el dispositivo del que procedían las fotos estaba en esa posición al subirlas. Si el perito sube directamente junto al vehículo, ese es el lugar de la inspección. Si sube por la tarde en la oficina, es la oficina, y el informe no debería leerse entonces como si allí figurara la ubicación del vehículo.
Esta distinción no es una carencia, sino la razón por la que la indicación es fiable. Una coordenada de la foto sería una afirmación de la cámara que tras la reducción ya no podría verificarse. Una coordenada de la subida es una observación de la plataforma en un momento registrado. Quien quiera probar el lugar de la inspección sube las fotos in situ.
Qué aparece en el PDF y en el portal
En el PDF del informe cada foto lleva un pie con los metadatos probatorios disponibles: el momento de la toma en la notación del idioma correspondiente y, si se guardó, la coordenada. Si falta uno de los dos, falta también en el pie; la plataforma no rellena. Las fotos mismas están en un almacenamiento privado, no bajo direcciones públicas; el acceso se realiza mediante enlaces firmados de validez limitada, para la visualización una hora. En la cuadrícula de captura se muestran vistas previas reducidas de 640 píxeles; quien quiera marcar una foto en el editor recibe para ello expresamente el archivo original en la resolución guardada, porque las marcas de daños sobre una vista previa serían demasiado toscas para un informe fiable.
Cada foto lleva además su procedencia: si la subió el perito en la captura o el cliente a través del enlace previo. Ambas son fuentes admisibles, pero no son lo mismo, y un informe que utiliza fotos del cliente debería decirlo. El etiquetado, el orden y la asignación al encargo son datos de trabajo del perito; los dos metadatos probatorios son lo que la plataforma ha tomado del archivo y del dispositivo, y no se afirma nada más.
Qué no guarda la plataforma, y qué queda por ello en manos del perito
El límite es fácil de trazar. DIAVAG guarda una copia reducida y recodificada de cada foto con dos metadatos probatorios. No guarda el archivo original, ni su bloque completo de metadatos, ni su suma de verificación, ni el dato GPS de la cámara. Quien en un procedimiento posterior deba presentar la toma inalterada no puede obtenerla de la plataforma. Está, si acaso, en el dispositivo de captura o en una copia de seguridad propia del despacho.
De ahí se deriva una regla de trabajo que no cuesta nada: conservar los originales. Una carpeta por encargo en el teléfono o en la copia de seguridad del despacho, sin alterar, con todos los metadatos, es la base probatoria; la plataforma es el lugar donde las fotos llegan al informe y al portal. Quien confunde ambas cosas tiene en un litigio un PDF de alta resolución y ningún archivo original. El principio es el mismo que para cualquier medición: ningún valor sin fuente, y la fuente de una foto es el archivo que escribió la cámara.
DIAVAG es una plataforma de software para peritos. No emplea peritos propios ni elabora informes; pone a disposición la captura, el borrador y la entrega bajo la marca propia del perito. En las fotos toma el momento de la toma del archivo y la ubicación del dispositivo con permiso, comprueba la plausibilidad de ambos y solo muestra lo que ha superado esa comprobación. Si una foto muestra lo que el informe afirma lo decide el perito que la tomó y la etiquetó.
Preguntas frecuentes
- ¿Se guardan los datos EXIF de mis fotos en DIAVAG?
- Solo dos datos de ellos: el momento de la toma de la etiqueta DateTimeOriginal y, si existe, la zona horaria de OffsetTimeOriginal. Ambos se leen en el navegador antes de reducir la imagen, porque al reducir se pierden todos los datos EXIF. Modelo de cámara, exposición, datos GPS y notas del fabricante no se transfieren.
- ¿Qué ocurre si una foto no lleva momento de la toma?
- El campo queda vacío y en el PDF no aparece ninguna fecha bajo la foto. La plataforma no pone en su lugar el momento de la subida; ese se registra por separado. Afecta a capturas de pantalla, archivos PNG, imágenes limpiadas o procesadas y fotos cuyo momento queda fuera de la ventana de plausibilidad.
- ¿Qué momentos descarta el servidor?
- Momentos que estén más de 24 horas en el futuro y momentos con más de 10 años de antigüedad. La tolerancia hacia delante absorbe relojes de dispositivo mal ajustados y zonas horarias ausentes; el límite hacia atrás descarta las indicaciones de marcador de los bloques EXIF vacíos. La regla rige por igual para las subidas del perito y para las fotos del cliente a través del enlace previo.
- ¿La ubicación guardada procede de la foto?
- No. Se guarda la posición del dispositivo que sube las fotos en el momento de la subida, consultada mediante la función de ubicación del navegador y solo con permiso del usuario. El dato GPS de la foto no se lee. Quien quiera probar el lugar de la inspección sube las fotos in situ.
- ¿Puedo descargar más tarde el archivo original desde DIAVAG?
- No. La plataforma guarda una copia JPEG reducida a un lado largo de 2000 píxeles con el momento de la toma y, en su caso, la ubicación. El archivo original inalterado con todos los metadatos permanece en el dispositivo de captura o en la copia de seguridad propia del despacho y debería conservarse allí para una prueba posterior.
Nos pondremos en contacto con usted personalmente.
Sin newsletter ni listas de distribución: regístrese si desea saber más sobre la plataforma; nos pondremos en contacto directamente con usted.
