Case study · Computer vision (proof of concept)

Flagging unexamined zones during a live endoscopy

We ran a proof of concept for an endoscope manufacturer: testing whether tracking which areas of the field had already been seen could flag a nearby, already-passed zone worth a second look - on an analysis stream kept fully separate from the live feed, with no way to interfere with the procedure or put the patient at risk.

Talk to us about medical computer vision See how it worked

Domain · Healthcare / endoscopy equipment Engagement · Proof of concept Approach · Parallel-stream zone tracking

The challenge

A narrow field of view misses what's just outside it

During an endoscopic procedure, the camera shows one narrow field of view at a time. Areas just outside that frame - tissue the scope passed moments ago, or the zone the physician hasn't reached yet - can go unexamined even when something in them is worth a second look.

The goal was to test whether tracking what had already been seen could close that gap - on an analysis stream kept isolated from the live procedure, so it had no way to interfere with it or put the patient at risk.

Discovery

Where we started before writing any code

Before building anything, we scoped the manufacturer's existing pipeline and hardware, and ran into a known set of hard problems endoscopy imagery actually throws at you.

What we set out to understand

What image postprocessing and CV/ML the manufacturer already had in place, if any.

Where image quality fell short, and what they wanted improved.

The equipment in use - cameras, optics, video processors, stream frame rate - and whether CV/ML could realistically be added to it.

How much delay would be acceptable if a given task couldn't run in true real time.

Problems we ran into

Real obstacles that came up while working the imagery - not just the zone-tracking problem itself:

Tissue segmentation and anomaly detection

Low lens resolution, low light, and peripheral vignetting

Calibration, reflections, and image rectification

Augmented reality and 3D reconstruction from 2D frames

Real-time processing constraints

How it worked

From a live feed to a proximity flag

Four stages took the system from the live video feed to a flag the physician could act on, without touching the procedure itself.

Zone tracking Already seen

As the scope moved, the system kept a running record of which areas of the field had already been passed - not just what was on screen right now.

Parallel analysis Isolated from the procedure

Analysis ran on a stream parallel to the live feed, kept fully separate from the procedure itself - with no way to interfere with it or put the patient at risk.

Proximity flagging Nearby zones

When a nearby, already-passed area showed something that might warrant another look, it was surfaced - not buried in a review queue after the fact.

Physician in control No auto-diagnosis

The system surfaced where attention might be warranted. The read, and the decision, stayed with the physician.

Why it holds up

What a proof of concept can honestly claim

What it validated

Tracking already-seen zones, not just the current frame.

Analysis stayed isolated from the live feed - no way to interfere with the procedure or put the patient at risk.

The hypothesis held on the footage available at the time.

Any decision stayed with the physician, not the system.

Scope of this case

A proof-of-concept engagement for an endoscope equipment manufacturer, not a deployed product.

No production rollout followed from this phase.

No metrics or technical specifics survive from the project beyond what's described here.

Client anonymized, consistent with how we describe every case.

Get started

Need to validate an idea before committing to build it?

We run proof-of-concept engagements that test whether an approach actually works before anyone commits to a full build.

Book a discovery call

Clients own the code - no lock-in.

Anonymized case study. Client details are confidential; described by domain and outcome.