Handwritten Exam Marks Reader for Cover Sheets and Result Entry

The problem teachers face after marking

Marking is only half the job. After a teacher marks a stack of answer books, someone has to add up the per-question marks on each cover sheet, check the total, and type every number into the university portal or a spreadsheet. For a class of 60 with eight questions that is close to 500 numbers typed by hand, often late at night before a result deadline. Addition mistakes and typing slips are common, and they surface later as rechecking requests, which cost the exam office far more time than the original entry.

The pain is sharpest in schools and universities that still run paper exams, which is most of them. The marks already exist on paper in a fixed table. The only missing piece is reading them reliably.

What already exists and the gap

• Gradescope lets instructors grade scanned exams online and reads student names with handwriting recognition, but the whole course has to be set up and graded inside Gradescope, which most departments do not do.
• ZipGrade and other optical mark recognition apps read bubble sheets well, but they need students to fill bubbles, not teachers to write numbers.
• General OCR services such as Google Cloud Vision read printed text reliably and handwritten digits inside small boxes much less so, and they know nothing about totals or roll numbers.

Researchers have published a very similar tool: a recent Springer conference paper on recognising handwritten points on exam cover sheets used 2D markers and a CNN and reported that teachers entered marks about three times faster. That is encouraging evidence that the idea works, and a clear gap: nothing packaged, free and usable by an ordinary teacher with a phone.

What you build

Three pieces. First, a cover sheet template with a marks grid and four printed ArUco markers at the corners. Markers make the geometry problem easy: you detect them with OpenCV, compute a perspective transform and get a perfectly straight grid even from a tilted phone photo.

Second, a recognition pipeline: split the grid into cells, detect empty cells, and classify each filled cell as a number from 0 to 99 with optional half marks. Start from a small CNN trained on MNIST, then fine-tune on digits you collect from real teachers, because real marks are written quickly in red pen, not in careful MNIST style.

Third, a review and export app: the teacher uploads a batch, sees each sheet with uncertain cells highlighted, fixes the few that need it, and exports a clean CSV keyed by roll number. The recognised question marks are summed and compared with the handwritten total, which gives you a free built-in error check.

The technically interesting part

The core challenge is knowing when you are wrong. A digit model that is 98 percent accurate per cell will still get several cells wrong on every batch, and a teacher will not trust a tool that silently types a 7 as a 1. Your job is calibration: use softmax confidence, temperature scaling or a small ensemble so that low confidence really does mean likely error, then route only those cells to the human. Show your evaluators a coverage versus error curve: at each confidence threshold, what share of cells is accepted automatically and what error rate remains among them. The total-check adds a second, independent signal, and you can measure how many errors it catches that confidence alone misses.

How to evaluate it

• Per-cell digit accuracy on a held-out set of sheets from teachers who did not contribute training data.
• The coverage versus error curve described above, with the threshold you chose and why.
• Sheet-level accuracy after review: the share of exported rows that exactly match a manually verified ground truth.
• A timed trial with at least five teachers entering the same 30 sheets manually and with the tool, reporting minutes per sheet and errors per sheet.

Suggested plan

1. Weeks 1 to 2: design the template, print it, collect 50 filled sheets from friends acting as teachers.
2. Weeks 3 to 5: marker detection, perspective correction and cell splitting, with a visual debug view.
3. Weeks 6 to 8: train on MNIST, collect real digits, fine-tune, calibrate confidence.
4. Weeks 9 to 11: review screen, total checking, export.
5. Weeks 12 to 14: timed trial with teachers and write-up.

Path to a product

The first customer is a school or private college exam office that processes thousands of cover sheets a term. Sell a per-campus annual licence with the template printed into their existing answer books, or offer it free to individual teachers and charge institutions for batch mode and portal export. Scaling means supporting more templates, not more model: each institution's sheet becomes a configuration file.

Scope warning

Do not try to read free-form handwriting, grade answers or read marks written anywhere on the page. The template is what makes this reliable. Do not build a full exam management system either; export to CSV and let existing systems import it.

Learn what you need on Sefism

• Machine Learning roadmap : covers the CNN basics and training loop you need for the digit model.
• Machine Learning cheat sheet : quick reference for evaluation metrics and overfitting checks.
• Google Colab : free GPU time to train and fine-tune the recogniser.
• Kaggle Datasets : extra handwritten digit sets to mix with MNIST before fine-tuning.
• Which final year project helps you get a job? : how to present a small, measured project well.

Get help with this idea

The two decisions that shape this project are the template design and the confidence threshold for human review. A mentor can help you sanity-check both before you collect data. Bring your draft scope, the dataset you plan to use and your evaluation table, and we can look at them together. The build is yours; the guidance is on scope, stack and how to measure it. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session