Skip to content
Learning PlatformsD-07Previous work

MarkFlow

Automatic marking for multiple-choice papers, entirely in the browser

Timeline
2026
Availability
Not publicly reachable
Repositories
1
Role
Design, OMR engine and implementation
Summary
A teacher photographs a stack of filled answer sheets and MarkFlow reads every one — locating the page, correcting for rotation, sampling each bubble, matching the paper to a student by the roll number they shaded, and building the mark book. No server, no special scanner.
200
Questions per sheet
the geometry the engine is measured against
7
Screens
exams, sheets, students, settings

What it is

Marking objective papers by hand is hours of work that produces no insight — the teacher already knows the answers, they just have to compare 200 bubbles per student against them. MarkFlow does the comparison. It is built around one specific artefact: the standard pre-printed NEET-style answer sheet, 200 questions in column blocks, four options each, with a ten-column grid where the student shades their roll number.

The whole flow is: create the exam, print a sheet per student, shade the correct answers on one sheet and photograph it as the key, then upload the class’s sheets in a batch. Every paper comes back graded and attached to a student.

Why there is no OpenCV

The recognition engine is plain Canvas 2D, written against measured sheet geometry rather than a general-purpose vision library. That was the decision the rest of the product hangs off, and it is what makes the app installable as a static page with nothing behind it.

The pipeline is six stages: decode and downscale the photo, estimate what counts as paper-white and ink-black in this photograph, find the page corners from the bright region, fit a homography from sheet space to image pixels and refine it against the four printed timing marks, then sample every bubble’s fill ratio through that transform.

Two details do most of the work. Orientation is recovered rather than assumed — both rotations are tried and the one whose printed example bubble reads dark is kept, so a sheet fed in upside down still marks correctly. And bubble sampling is chroma-aware, because the sheet is printed in pink and filled in blue or black pen; discriminating on colour rather than darkness alone is what stops printed guides being read as marks.

Being wrong loudly

An automatic marker that silently misreads is worse than no marker, because the error arrives with a student’s grade attached. So the engine classifies rather than guesses: every question is answered, blank, multiply marked or faintly marked, and the last three are flagged. Flagged sheets get a review screen that draws what the engine detected on top of the actual photograph, so the teacher adjudicates the image rather than trusting a number.

Two escape hatches exist for the cases the geometry cannot rescue, both off by default and switched on by the teacher: reading the handwritten name and roll number off a sheet that failed to match any student, and a whole-sheet read for a photograph that will not align at all. Anything that comes back that way is flagged for review regardless of confidence. That optional assist is also the only part of the product that sends an image anywhere — ordinary marking, and every sheet image and result, stays in the browser’s own database on the device.

Testing an image pipeline without a classroom

The engine needed to be verified against imperfect input before any real sheets existed, so the repository carries a synthetic filler: it takes the real sheet image, shades it the way a student would with imperfect pen strokes, then adds the things a phone camera contributes — rotation, a brightness gradient across the page, an off-white background. That generator is what the demo data comes from as well.

Next product
SDLC Orchestrator

Turning a plan into sequenced, machine-executable work units