Most image pipelines are designed around delivery.
Take a large upload, rotate it correctly, resize it, compress it, and keep the version the application can display efficiently. That is usually a sensible way to build a website.
Markit had a different requirement. The photographs were not decoration. They were evidence used to identify an object, read its markings, assess condition, and support a valuation. Once I treated them that way, an optimized derivative could no longer be the only copy.
The First Model Will Not Be The Last Reader
A review image that looks perfectly adequate in a browser may have discarded the detail needed for a later question.
A faint maker’s mark might matter after the object has been tentatively identified. Future OCR may read a label that the current tool missed. A different vision model may use details that seemed irrelevant during the first pass. A human reviewer may simply want to zoom further into a scratch, seam, signature, or serial number.
Recompressing the upload before preserving it would make the first processing decision irreversible. That is a poor trade when the original file is part of the research record.
Markit therefore stores each photograph as a small bundle:
- The untouched original upload.
- A display-sized WebP for review and vision calls.
- A smaller WebP thumbnail for browsing.
The application also records the original filename, dimensions, file type, byte sizes, and a SHA-256 checksum. The derivatives make the interface fast. The original keeps the process auditable.
A Checksum Is More Than Duplicate Detection
The checksum prevents the same photograph from being attached to an item twice, but it also provides a stable fact about the evidence.
Filenames change. Files move between a phone, a synced folder, and a desktop. Two cameras can produce the same generic filename. A hash lets the application recognize the bytes rather than trusting the label attached to them.
That distinction becomes especially useful when intake can happen several ways. Markit accepts normal browser uploads, phone-camera capture, drag and drop, and imports from a local or synced folder. The path changes; the identity of the original does not.
One Bad File Should Not Erase A Good Batch
Evidence intake also changed how I thought about upload errors.
If a batch contains nine valid photographs and one invalid file, rejecting the entire batch is technically tidy and operationally hostile. The user has to determine which file caused the problem and repeat work the system had already proven it could perform.
Markit processes each file independently. Valid images are preserved and receive their derivatives. Invalid files are skipped. The result reports both successes and failures, so partial success is visible rather than silently presented as completion.
This is not transactional purity, but it matches the real unit of work. Each photograph is independent evidence. A broken tenth file should not revoke the other nine.
Derivatives Are Disposable, Originals Are Not
The current display size and compression settings are implementation choices. They can change as browsers, storage costs, and model requirements change. Every derivative can be regenerated from the original.
The reverse is impossible.
That creates a useful hierarchy: originals are retained evidence; derivatives are replaceable working copies; database metadata is an index into both. Optimization still matters, but it happens downstream from preservation.
The general lesson is not that every application must keep every upload forever. It is that an image pipeline should begin by deciding what the image represents. If it is merely a delivery asset, replacement may be harmless. If it is evidence, the system needs an undo button before it makes the first destructive choice.