Calibrated colour matching on a phone camera: CIE LAB for field inspection

1. The problem: visual inspection is unreliable

Facilities services teams run on field technicians who travel between venues and carry out quality checks and maintenance work. The quality checks are usually done by eye. A technician looks at a sample, compares it against their memory of what a good sample looks like, and grades it.

This produces three recurring problems.

Inter-rater disagreement. Two technicians can look at the same sample under the same lighting and grade it differently. Across a portfolio of venues that inconsistency shows up as noise in every downstream report, every operational decision, and every conversation with a customer who has a question about a recent visit.

Illuminant variance. The same sample photographed in a bright outdoor setting and in a dim basement reads as different colours to the human eye, because human colour perception adapts to the light source. Technicians try to compensate but they cannot do it reliably.

No audit trail. Verbal grades do not produce evidence. If a customer disputes the quality of service, or a regulator audits the process, there is nothing to review beyond the technician’s notes. This matters for procurement, for compliance, and for the company’s own ability to trust its own data.

Each of these degrades the signal that comes back from the field. The ambition of this project was to make the measurement layer reliable enough that whoever consumes its output can actually trust it.

2. Why RGB is the wrong colour space for this

The obvious approach is to photograph the sample and match its colour against a reference. The catch is that the native colour space of cameras, RGB, is almost useless for this purpose.

Three reasons.

RGB is gamma-encoded. RGB values in a typical image are not linear. A mid-grey pixel at RGB(128, 128, 128) does not represent 50% of the light of a white pixel at RGB(255, 255, 255). This means arithmetic on RGB values does not mean what you would expect, and distance in RGB space does not correspond to perceptual colour difference.

RGB is illuminant-dependent. The same physical surface produces different RGB values under different lighting. Warm indoor light shifts everything red; daylight is bluer. Without a calibration step the lighting conditions leak into the measurement.

RGB is not perceptually uniform. Two RGB differences of equal Euclidean magnitude can look very different to the human eye. A small shift in dark blues is perceptually nothing; the same shift in light yellows is visible. Matching in RGB produces either false positives or false negatives depending on the colour range.

Any of these problems individually would be a serious obstacle. All three together mean RGB-based matching in field conditions does not work.

3. CIE LAB and the phone camera

CIE LAB is a colour space specifically designed to address these problems. It separates lightness (L) from two chromatic axes (a for red-green, b for yellow-blue). Distances in LAB space correspond closely to perceived colour differences, which means the standard distance metric, Δ E 2000, produces numbers that match human judgments of “close” and “far”. LAB also carries a notional illuminant, so the same surface under different lights can be normalised to a reference white point.

Converting camera data to LAB is not magic. It requires a known colour reference in the frame so the camera’s per-shot white balance and exposure can be inverted. This is the heart of the calibration problem.

4. The calibration card: anchoring camera output

Every photograph taken with the app includes a small colour calibration card in the frame, alongside the sample being measured. The card has a known set of reference patches whose true LAB values are known in advance. The app detects the card, reads the RGB values of each patch in the captured image, and computes the transform that maps those captured values back to the reference values. That transform is then applied to the sample’s RGB values to get its “true” LAB coordinates.

In practice we use a simple affine transform per channel. More sophisticated approaches (3x3 colour correction matrices, polynomial fits, thin-plate splines) give slightly better accuracy but they add failure modes at the edges of the gamut. For a Δ E 2000 target of around 2, which is the threshold below which two colours are indistinguishable to a trained eye, the simple transform is enough. What matters more than the maths is the calibration card being visible, well-lit, and in focus in every shot.

The practical work in this section is therefore less about colour science and more about making sure the camera actually captures what it needs to. That leads into the UX and architecture sections.

5. Offline-first PWA architecture

We shipped LineSpec as a Progressive Web App rather than a native iOS and Android app. Three reasons for the choice.

Distribution. Field teams rotate. Onboarding a new technician by sending them a URL is fundamentally faster than walking them through an app store installation, especially on company devices with restricted app stores. New technicians scan a QR code on a training sheet and are using the tool within seconds.

Deployment velocity. A PWA ships whenever we push. No review queues, no version fragmentation, no support cost for users on last month’s build. Calibration improvements reach every technician instantly.

Cross-platform maintenance. One codebase for iOS and Android. A small team cannot maintain two native apps responsibly.

The trade we accept is reduced camera control. Native camera APIs let you lock exposure, focus, and white balance in ways that browser camera APIs partially expose but never fully. We compensate with on-screen framing overlays that make the shot consistent enough, and with the colour calibration card that corrects what the camera auto-processes.

Offline support is non-negotiable. Cellars have no signal. The app uses a service worker to cache everything needed offline (app shell, reference data, calibration tables) and an IndexedDB-backed queue for inspection records waiting to sync. When the device reconnects, the queue drains in the background. A technician never has to think about it.

6. UX under field conditions

The UX problem in this product is more constrained than most. The technician is often in a cellar, often holding something with one hand, often on a tight schedule, and has one shot at capturing each sample. The interface has to make the capture as close to thoughtless as possible.

We guide the shot with a full-screen viewfinder overlay that shows the technician exactly where the sample should sit and exactly where the calibration card should sit. Capture is one tap. Immediately after, the app shows the measured LAB values, the Δ E 2000 against the reference, and a clear pass or fail. The technician either moves on or retakes. If they retake, the earlier capture is kept in the audit trail with a flag so there is no ambiguity about which result is the final one.

Good UX here is not visual polish. It is removing the moments where a tired technician could get it wrong, and making sure every capture produces a useful record even when the technician makes no decisions at all.

7. The measurement layer and what sits on top of it

A tool that measures quality is only as useful as the decisions that consume its output. The interesting downstream question is what an operations team does with a stream of trusted quality readings that they did not have before.

Some teams use it to flag venues drifting outside the acceptable range and escalate those before the customer notices. Others use it to tune their existing maintenance patterns, adding visits where readings are trending poorly and relaxing them where quality is holding steady. A few use it as evidence in customer conversations, showing contract-level quality trends backed by measurement rather than anecdote.

None of that is decided by the measurement tool. The tool’s job is to produce readings good enough to be trusted in all of those contexts. The scheduling, escalation, and customer communication happen in systems the tool feeds. If the measurement is wrong or inconsistent, none of those systems can do their job.

That is why the technical focus of this project was calibration and consistency rather than anything higher up the stack.

8. What we would do differently

Two reflections.

First, we under-invested in training early on. The calibration card needs to be captured in the same frame as the sample, and in the first weeks we had a steady trickle of captures where one or the other was out of frame, poorly lit, or obscured. A proper onboarding video and a practice mode would have prevented most of this. We built the practice mode eventually. We should have built it first.

Second, we accepted the browser’s camera API constraints too readily. Some platforms (notably iOS Safari) have genuine limitations we cannot work around, but on Android Chrome there is more granular control available than we used in v1. A v2 would push harder on camera control to reduce the calibration work the software has to do after the fact.

Closing note

The instinct for a problem like this is to reach for the imaging tech. The imaging tech matters, but it is only useful if the measurement is trusted. Most of the engineering work that actually mattered was not in the LAB transform itself. It was in the calibration card workflow, the framing overlays, the offline queue, the retake-and-audit logic, and the small UX details that let a tired technician in a dim basement produce a reliable reading without thinking about it.

LineSpec is the measurement layer. Whatever the operations team decides to do with those measurements happens in separate systems that sit on top. The value of this tool is that those systems now have something real to consume.

If you are building something at the intersection of mobile computer vision and field operations, we are happy to compare notes.