Metadados probatórios nas fotos: o que a DIAVAG guarda e o que se perde ao reduzir a imagem

Uma foto do smartphone é normalmente muito maior do que precisa de ser para um PDF de relatório ou um portal de clientes. Para o carregamento, a DIAVAG reduz por isso cada imagem no navegador antes de ela chegar à plataforma: a um lado maior de 2000 píxeis, codificada como JPEG com um nível de qualidade de 0,82. Imagens em formato JPEG ou PNG que de qualquer forma não excedem 600 kilobytes ficam intactas; as capturas HEIC do iPhone e os ficheiros WebP são sempre convertidos, porque aí a conversão de formato é o verdadeiro objetivo.

Esta redução tem um efeito secundário decisivo para a preservação de provas: a imagem é carregada numa área de desenho e recodificada a partir daí, e nesse processo perdem-se todos os dados EXIF. Ao servidor chega uma imagem sem metadados. O único momento que o servidor conhece então por si próprio é o do carregamento, e esse está errado como momento da captura assim que o perito carrega as fotos no dia seguinte.

A orientação é o único valor de metadados que na redução não se perde, mas é aplicado: a imagem é rodada antes do desenho tal como a câmara anotou nos dados EXIF, e fica depois direita. Tudo o resto – modelo da câmara, objetiva, exposição, coordenadas GPS incorporadas, notas do fabricante e miniaturas – já não faz parte do ficheiro após a redução.

Como os metadados não sobrevivem ao carregamento, a DIAVAG lê o momento da captura no ficheiro inalterado antes da redução. O padrão Exif, que a Camera & Imaging Products Association mantém como CIPA DC-008, mais recentemente na versão Exif Version 3.1 com uma tradução publicada a 30 de janeiro de 2026, define para isso uma etiqueta chamada DateTimeOriginal. Contém o momento da captura como cadeia no formato «AAAA:MM:DD HH:MM:SS», com dois pontos também na parte da data. Uma segunda etiqueta, OffsetTimeOriginal, indica o fuso horário da captura, por exemplo «+02:00».

São lidas exatamente estas duas etiquetas, mais nada. O leitor é deliberadamente pequeno: lê apenas o início do ficheiro, 256 kilobytes, onde no JPEG o segmento com os dados EXIF está logo a seguir ao início do ficheiro e que cobrem também o cabeçalho de um ficheiro HEIC. Uma biblioteca que trouxesse centenas de etiquetas, notas do fabricante e outros formatos de metadados estaria fora de qualquer proporção face aos dois campos realmente necessários. DateTimeOriginal não está no primeiro diretório do ficheiro, mas num subdiretório para o qual aponta um ponteiro; o leitor segue esse ponteiro e procura aí as duas etiquetas.

O resultado é enviado como momento num formato inequívoco juntamente com o ficheiro reduzido, exatamente uma entrada por ficheiro na mesma ordem, para que o servidor possa associar os dois. Se um ficheiro não tiver um momento utilizável, porque é uma captura de ecrã, um PNG, uma imagem já limpa ou processada, é enviada uma entrada vazia. Uma foto sem data legível não é motivo para o carregamento falhar.

Duas particularidades do formato Exif exigem uma decisão. A primeira diz respeito ao fuso horário. DateTimeOriginal não o tem. Se a câmara escrever adicionalmente OffsetTimeOriginal, o que muitos smartphones e câmaras atuais fazem, o momento é inequívoco e é fixado através dele. Se a indicação faltar, a DIAVAG lê a hora como hora local do dispositivo que carrega. É a menor suposição possível neste fluxo: captura e carregamento acontecem no mesmo lugar, o perito junto ao veículo ou o cliente com o seu telemóvel. A alternativa, ler a hora como tempo universal, estaria na Alemanha sempre uma a duas horas ao lado.

A segunda particularidade é o marcador. Os blocos EXIF vazios contêm frequentemente a indicação «0000:00:00 00:00:00». Um analisador de datas ingénuo continua a calcular em silêncio com esses campos e chegaria a uma data no ano 1899. A DIAVAG verifica por isso, após a conversão, se saíram exatamente os campos que estavam na cadeia; se não for o caso, o ficheiro é considerado sem momento da captura.

Ambas as decisões devem ser declaradas no relatório quando isso importa. Um momento proveniente de DateTimeOriginal sem fuso horário é uma indicação de hora local sob a suposição de que o dispositivo que carregou estava no mesmo fuso horário que a câmara. Na esmagadora maioria dos trabalhos é o mesmo dispositivo. Onde não for assim, por exemplo com fotos que um cliente envia do estrangeiro, a reserva deve constar do texto.

O momento da captura chega ao servidor como indicação não verificada do cliente. É por isso aí verificado quanto à plausibilidade, não no navegador, porque os limites pertencem ao lugar onde a indicação é aceite. Valem dois limites. Para a frente: um momento que esteja mais de 24 horas no futuro é rejeitado; os relógios dos dispositivos andam mal e nos EXIF faltam os fusos horários, por isso a tolerância é generosa mas finita. Para trás: tudo o que tiver mais de 10 anos é igualmente rejeitado, porque um tal valor é, por experiência, um marcador ou um relógio avariado, não uma foto probatória para um trabalho em curso.

Se um momento cair fora da janela ou faltar, o campo fica vazio. A plataforma não põe no seu lugar o momento do carregamento. Esse é guardado em separado, como momento em que o ficheiro chegou, e é rastreável como tal a qualquer altura. No PDF, sob uma foto sem momento da captura não aparece deliberadamente nenhuma data. Uma data em falta é uma indicação honesta; uma data de carregamento apresentada como data da captura seria falsa.

A mesma regra vale em ambas as vias de carregamento. As fotos que o perito carrega no registo e as fotos que um cliente entrega ele próprio através da ligação prévia sem iniciar sessão passam pela mesma janela com os mesmos limites; ambas as vias têm de decidir de forma idêntica, senão a mesma foto teria uma data diferente consoante o remetente. Por trabalho são possíveis no total 40 fotos, das quais no máximo 12 através da ligação do cliente. Uma imagem que foi marcada no editor de fotos e guardada como novo ficheiro não tem momento da captura; a marcação é uma edição, e a data da edição não é a data da captura.

O segundo metadado probatório é a localização, e aqui a precisão na descrição importa mais do que a própria coordenada. A DIAVAG não guarda o dado GPS da foto. Esse perder-se-ia de qualquer modo após a redução, e também não é lido antes. É guardada a posição do dispositivo que carrega as fotos no momento do carregamento, consultada através da função de localização do navegador, sem alta precisão e com uma espera de no máximo cinco segundos. Se o utilizador não conceder a autorização ou o dispositivo não responder a tempo, não é guardada nenhuma localização.

No servidor, a coordenada é verificada quanto ao seu intervalo de valores e, caso contrário, rejeitada. No PDF aparece na legenda juntamente com o momento da captura, com cinco casas decimais. O que a coordenada prova fica assim claramente delimitado: o dispositivo de onde vieram as fotos estava nessa posição ao carregar. Se o perito carregar diretamente junto ao veículo, esse é o local da vistoria. Se carregar à noite no escritório, é o escritório, e o relatório não deve então ser lido como se aí constasse a localização do veículo.

Esta distinção não é uma falha, mas a razão pela qual a indicação é fiável. Uma coordenada da foto seria uma afirmação da câmara que após a redução já não poderia ser verificada. Uma coordenada do carregamento é uma observação da plataforma num momento registado. Quem quiser provar o local da vistoria carrega no local.

No PDF do relatório cada foto tem uma legenda com os metadados probatórios existentes: o momento da captura na notação da respetiva língua e, se guardada, a coordenada. Se faltar um dos dois, falta também na legenda; a plataforma não preenche. As próprias fotos estão num armazenamento privado, não sob endereços públicos; o acesso faz-se através de ligações assinadas com validade limitada, para a visualização uma hora. Na grelha de registo são mostradas pré-visualizações reduzidas de 640 píxeis; quem quiser marcar uma foto no editor recebe para isso expressamente o ficheiro original na resolução guardada, porque marcações de danos sobre uma pré-visualização seriam demasiado grosseiras para um relatório fiável.

Cada foto traz além disso a sua proveniência: se a carregou o perito no registo ou o cliente através da ligação prévia. Ambas são fontes admissíveis, mas não são a mesma coisa, e um relatório que utiliza fotos do cliente deveria dizê-lo. A etiquetagem, a ordem e a atribuição ao trabalho são dados de trabalho do perito; os dois metadados probatórios são o que a plataforma retirou do ficheiro e do dispositivo, e mais nada é afirmado.

O limite é fácil de traçar. A DIAVAG guarda uma cópia reduzida e recodificada de cada foto com dois metadados probatórios. Não guarda o ficheiro original, nem o seu bloco completo de metadados, nem a sua soma de verificação, nem o dado GPS da câmara. Quem num processo posterior tiver de apresentar a captura inalterada não a pode obter da plataforma. Ela está, quando muito, no dispositivo de captura ou numa cópia de segurança própria do gabinete.

Daí decorre uma regra de trabalho que nada custa: conservar os originais. Uma pasta por trabalho no telemóvel ou na cópia de segurança do gabinete, inalterada, com todos os metadados, é a base probatória; a plataforma é o lugar onde as fotos chegam ao relatório e ao portal. Quem confunde as duas coisas tem, em litígio, um PDF de alta resolução e nenhum ficheiro original. O princípio é o mesmo de qualquer medição: nenhum valor sem fonte, e a fonte de uma foto é o ficheiro que a câmara escreveu.

A DIAVAG é uma plataforma de software para peritos. Não emprega peritos próprios nem elabora relatórios; disponibiliza o levantamento, o rascunho e a entrega sob a marca própria do perito. Nas fotos retira o momento da captura do ficheiro e a localização do dispositivo com autorização, verifica a plausibilidade de ambos e só apresenta o que passou nessa verificação. Se uma foto mostra o que o relatório afirma, decide-o o perito que a tirou e etiquetou.