Evidence metadata in photos: what DIAVAG stores and what is lost when downsizing

A photo from a smartphone is usually far larger than it needs to be for a report PDF or a customer portal. For upload, DIAVAG therefore downsizes every image in the browser before it reaches the platform: to a long edge of 2000 pixels, encoded as JPEG at a quality setting of 0.82. JPEG or PNG images that are no larger than 600 kilobytes anyway are left untouched; HEIC captures from the iPhone and WebP files are always converted, because there the format conversion is the actual purpose.

This downsizing has a side effect that is decisive for preserving evidence: the image is loaded into a drawing surface and re-encoded from there, and in the process all EXIF data is lost. What arrives on the server is an image without metadata. The only time the server then knows itself is that of the upload, and that is wrong as a capture time as soon as the expert uploads the photos the following day.

Orientation is the only metadata value that is not lost during downsizing but applied: before drawing, the image is rotated as the camera recorded in the EXIF data, and afterwards stands upright. Everything else – camera model, lens, exposure, embedded GPS coordinates, maker notes and thumbnails – is no longer part of the file after downsizing.

Because the metadata does not survive the upload, DIAVAG reads the capture time from the unchanged file before downsizing. The Exif standard, maintained by the Camera & Imaging Products Association as CIPA DC-008, most recently in the version Exif Version 3.1 with a translation published on 30 January 2026, defines a tag named DateTimeOriginal for this. It contains the time of capture as a string in the format “YYYY:MM:DD HH:MM:SS”, with colons in the date part as well. A second tag, OffsetTimeOriginal, gives the time zone of the capture, for example “+02:00”.

Exactly these two tags are read, nothing else. The reader for this is deliberately kept small: it reads only the beginning of the file, 256 kilobytes, in which for JPEG the segment with the EXIF data lies directly behind the start of the file and which also cover the header of a HEIC file. A library bringing hundreds of tags, maker notes and further metadata formats would be out of all proportion to the two fields actually needed. DateTimeOriginal is not in the first directory of the file but in a sub-directory pointed to by a pointer; the reader follows that pointer and looks for the two tags there.

The result is sent as a timestamp in an unambiguous format together with the downsized file, exactly one entry per file in the same order, so that the server can match the two. If a file carries no usable time – because it is a screenshot, a PNG, an already cleaned or further processed image – an empty entry is sent. A photo without a readable date is no reason to let the upload fail.

Two peculiarities of the Exif format require a decision. The first concerns the time zone. DateTimeOriginal carries none. If the camera additionally writes OffsetTimeOriginal, which many current smartphones and cameras do, the point in time is unambiguous and is fixed through it. If the information is missing, DIAVAG reads the time as local time of the uploading device. That is the smallest possible assumption in this workflow: capture and upload happen in the same place, the expert at the vehicle or the customer with their phone. The alternative, reading the time as universal time, would in Germany always be one to two hours off.

The second peculiarity is the placeholder. Empty EXIF blocks commonly contain the entry “0000:00:00 00:00:00”. A naive date parser silently carries such fields forward and would arrive at a date in the year 1899. DIAVAG therefore checks after conversion whether exactly the fields that were in the string came out; if not, the file counts as having no capture time.

Both decisions should be disclosed in the report where it matters. A timestamp taken from DateTimeOriginal without a time zone is a local-time statement under the assumption that the device that uploaded was in the same time zone as the camera. In the vast majority of jobs it is the same device. Where it is not – for instance photos a customer sends from abroad – the reservation belongs in the text.

The capture time arrives on the server as an unverified statement from the client. It is therefore checked for plausibility there, not in the browser, because the limits belong where the statement is accepted. Two limits apply. Forwards: a timestamp more than 24 hours in the future is discarded; device clocks run wrong and time zones are missing in EXIF, so the tolerance is generous but finite. Backwards: anything older than 10 years is likewise discarded, because such a value is in practice a placeholder or a broken clock, not a piece of evidence for a current job.

If a timestamp falls outside the window or is missing, the field stays empty. The platform does not put the upload time in its place. That is stored separately, as the time the file arrived, and is traceable as such at any time. In the PDF, a photo without a capture time deliberately carries no date. A missing date is an honest statement; an upload date presented as a capture date would be a false one.

The same rule applies on both upload routes. Photos the expert uploads during capture and photos a customer submits themselves via the pre-capture link without logging in pass through the same window with the same limits; both routes must decide identically, otherwise the same photo would carry a different date depending on the sender. Per job a total of 40 photos is possible, of which at most 12 via the customer link. An image that has been marked up in the photo editor and saved as a new file carries no capture time; the mark-up is an edit, and the date of the edit is not the date of capture.

The second piece of evidence metadata is the location, and here precision in the description matters more than the coordinate itself. DIAVAG does not store the GPS data from the photo. It would be lost after downsizing anyway, and it is not read beforehand either. What is stored is the position of the device uploading the photos at the time of upload, queried via the browser's location function, without high accuracy and with a wait of at most five seconds. If the user does not grant permission or the device does not respond in time, no location is stored.

On the server the coordinate is checked against its value range and otherwise discarded. In the PDF it appears in the caption together with the capture time, with five decimal places. What the coordinate proves is thus clearly delimited: the device the photos came from was at this position when uploading. If the expert uploads directly at the vehicle, that is the place of the inspection. If they upload in the evening at the office, it is the office, and the report should then not be read as if it stated the vehicle's location.

This distinction is not a shortcoming but the reason why the statement is reliable. A coordinate from the photo would be an assertion by the camera that could no longer be verified after downsizing. A coordinate of the upload is an observation by the platform at a logged point in time. Anyone wanting to prove the place of inspection uploads on site.

In the report PDF every photo carries a caption with the evidence metadata that exists: the capture time in the notation of the respective language and, if stored, the coordinate. If either is missing, it is missing from the caption too; the platform does not fill in. The photos themselves lie in private storage, not under public addresses; access runs via signed links with limited validity, one hour for display. In the capture grid, downsized previews of 640 pixels are shown; anyone wanting to mark up a photo in the editor receives for that purpose the original file in the stored resolution, because damage markings on a preview would be too coarse for a reliable report.

Each photo also carries its origin: whether the expert uploaded it during capture or the customer via the pre-capture link. Both are admissible sources, but they are not the same, and a report that uses customer photos should say so. The labelling, the order and the assignment to the job are the expert's working data; the two pieces of evidence metadata are what the platform took from the file and from the device, and no more is claimed.

The line is easy to draw. DIAVAG stores a downsized, re-encoded copy of every photo with two pieces of evidence metadata. It does not store the original file, its complete metadata block, its checksum or the camera's GPS data. Anyone who has to present the unaltered capture in later proceedings cannot retrieve it from the platform. It lies, if at all, on the capturing device or in the office's own backup.

From this follows a working rule that costs nothing: keep the originals. A folder per job on the phone or in the office backup, unaltered, with all metadata, is the evidential basis; the platform is where the photos get into the report and the portal. Anyone who confuses the two has, in a dispute, a high-resolution PDF and no original file. The principle is the same as for every reading: no value without a source, and the source of a photo is the file the camera wrote.

DIAVAG is a software platform for experts. It employs no appraisers of its own and produces no reports; it provides capture, drafting and delivery under the expert's own brand. For photos it takes the capture time from the file and the device's location with permission, checks both for plausibility and outputs only what has passed that check. Whether a photo shows what the report claims is decided by the expert who took and labelled it.