Computer Vision Syndrome vs Evaluating Computer Vision Models

An honest coincidence

If you search for 'computer vision syndrome' you will land on optometry pages describing dry eyes, headaches, and blurred vision caused by prolonged screen use. If you search for 'computer vision evaluation' you will land on machine learning material about precision, recall, and dataset splits. These two things have nothing to do with each other beyond sharing the word 'vision'. One is a cluster of physical symptoms named by clinicians in the 1990s to describe a real occupational hazard. The other is a subfield of artificial intelligence concerned with teaching machines to interpret images.

I bring this up not because the overlap is profound, but because it is a useful, low-stakes example of something that trips people constantly in technical fields: names collide, and sloppy reading fills the gap with assumption. Someone skimming a search results page, half paying attention, might genuinely wonder for a second whether staring at a monitor somehow degrades a neural network's accuracy. It does not. But the fact that the question can even arise is a small case study in why precise terminology and careful reading matter more than we tend to admit.

The rest of this post is really about the second half of that pairing: how you actually evaluate a computer vision model properly. I will use the naming coincidence as a hook, then spend most of the space on the part that has genuine technical substance, because that is the part worth teaching well.

What computer vision syndrome actually is

Computer vision syndrome, sometimes called digital eye strain, is a recognised set of symptoms associated with extended near-work on screens: eye fatigue, dryness, blurred vision, headaches, and neck or shoulder discomfort. It is caused by things like reduced blink rate during screen focus, glare, poor posture, and uncorrected vision problems interacting with sustained close-range viewing. It is a physiological and ergonomic issue, addressed with breaks, screen positioning, lighting adjustments, and eye examinations.

None of that has any bearing on machine learning. I mention it briefly and then set it aside deliberately, because the temptation in a piece like this is to force a clever connection where none exists. There isn't one. The syndrome is about human eyes and screens. The evaluation problem is about how confidently you can trust a piece of software that classifies, detects, or segments images. Treating them as related would be exactly the kind of imprecise thinking that good evaluation practice is meant to guard against.

Evaluating a vision model properly

Here is where the real content lives. Suppose you have trained an image classifier to distinguish healthy from damaged industrial components on a production line, and it reports 97 percent accuracy on your test set. That number, on its own, tells you almost nothing trustworthy until you interrogate how it was produced.

The first question is class balance. If 95 percent of components in your dataset are healthy, a model that always predicts 'healthy' scores 95 percent accuracy while being completely useless. You need precision and recall on the minority class, or a confusion matrix, not a single headline number. If your damaged-component recall is 40 percent, the model is missing more than half the actual defects, which is the exact failure mode the system exists to prevent.

The second, more insidious question is leakage. Imagine your images come from ten production batches, and frames from the same physical component appear multiple times under slightly different lighting because they were captured on a rolling camera. If you split train and test randomly at the image level rather than at the component or batch level, near-duplicate images of the same physical object end up on both sides of the split. The model then partly memorises specific instances rather than learning general defect patterns, and your test accuracy becomes an optimistic fiction. A model that looks like it scores 96 percent under a naive random split might genuinely perform closer to 80 percent once you split by batch and force the test set to contain components the model has never seen in any form.

The third question is what your baseline actually is. A deep convolutional network that gets 89 percent accuracy sounds impressive until you learn that a simple threshold on average pixel brightness gets 85 percent, because damaged components happen to be visibly darker in this dataset. Suddenly the network's extra four points look far less like sophisticated visual understanding and far more like it learned a shortcut that correlates with the label for uninteresting reasons. Strong, boring baselines are not a formality; they are the thing that tells you whether your fancy model is earning its complexity.

The fourth question is distribution shift. A vision model evaluated on images captured under the same lighting rig and camera angle as training will look far stronger than it will in deployment, where lighting varies, cameras get replaced, and components arrive with wear patterns the training set never saw. Reporting performance on a held-out set drawn from the identical capture conditions as training data is common, and it is also one of the most reliable ways to be surprised, unpleasantly, six months after deployment.

The practical takeaway

The joke buried in the shared name is that computer vision syndrome is at least honestly named: it describes exactly what it is, a syndrome caused by looking at screens. Computer vision evaluation deserves the same honesty. A single accuracy figure is not evaluation; it is a headline that might be hiding class imbalance, leakage, a weak baseline comparison, or a training distribution that has nothing to do with the deployment environment.

If you take one habit from this, make it a checklist you run before trusting any reported number: check class balance and use metrics that reflect it, check whether the split respects natural groupings in the data to avoid leakage, compare against a genuinely simple baseline, and ask whether the test conditions resemble where the model will actually be used. None of these require exotic tools. They require discipline and a willingness to be sceptical of your own good news, which is, appropriately enough, exactly the kind of care that keeps both your eyes and your models in reasonable working order.