Extract marked fields from scanned forms, surveys, and tests in C#. The SDK detects filled bubbles, checkboxes, and ovals, and it uses an anchoring system to handle scan-to-scan alignment differences automatically.
Read filled bubbles on exams, quizzes, and assessments. Detect squares, circles, and ovals with or without characters inside.
Process questionnaires, feedback forms, and satisfaction surveys. The SDK tells you which fields are marked and which are not.
Capture check-in sheets, roll calls, and registration forms. Batch-process stacks of scanned pages in a loop.
Digitize inspection checklists and audit forms. Extract pass/fail marks from fields of any supported shape.
TEMPLATE SETUP
Create an OMR template by specifying an anchor (a logo or rectangle that appears on every form) and the rectangles surrounding each mark field. The anchor is used to measure scan-to-scan alignment differences, so the SDK knows where to look on each filled form.
Choose a logo, rectangle, or solid object as the anchor. The SDK finds it on each scan and calculates the X/Y offset to correct for scanner placement differences.
Define OMR fields as rectangles on the template. The SDK applies the measured offset to locate the same fields on every filled form.
Capture anchor and field coordinates interactively using the built-in viewer control, or specify them in code with exact pixel values.
Scan templates and forms directly from your application using the built-in TWAIN and WIA driver support.
MARK EXTRACTION
For each scanned form, the SDK locates the anchor, measures the alignment offset, adjusts all field positions, and runs mark detection. Results come back as a simple integer array — 1 for filled, 0 for empty.
Detect square, circular, and oval marks. Each shape category has its own detection function optimized for that geometry.
Handle marks that contain letters or numbers (A, B, C, D). The detection functions accept a parameter to account for character content.
Control how much fill a field needs to count as marked. The SDK also returns a confidence value for each result.
Choose between speed-optimized and accuracy-optimized anchor search. Trade search area size for processing time based on your needs.
DEPLOYMENT
Nutrient’s OMR engine is part of the .NET SDK. Deploy it in desktop applications, Windows services, or server-side .NET processes — anywhere the .NET runtime is available.
Build interactive OMR tools with the built-in viewer control for WinForms or WPF. Let operators define templates visually and review results in the same application.
Process stacks of scanned forms in a background service or scheduled job. Loop through forms, extract marks, and write results to a database or CSV — no UI required.
Optical mark recognition (OMR) is the process of detecting filled fields on scanned documents — bubbles on exams, checkboxes on surveys, and ovals on registration forms. The SDK works by comparing a template (the blank form with field positions defined) against scanned filled forms. It uses an anchor to correct for alignment differences between scans. See the introduction to OMR for the full explanation.
Scan or load the blank form, define an anchor rectangle (a logo or solid object that appears on every copy), and specify the rectangles surrounding each mark field. You can capture coordinates interactively using the built-in viewer control, or set them in code. See the template guide for step-by-step instructions.
The SDK detects square, circular, and oval marks. Square and circular fields use the same detection function, while ovals have a separate one optimized for their geometry. Both functions support marks with or without characters (like A, B, C, D) inside them.
The anchor is a recognizable object (logo, rectangle, or solid shape) on the template. When processing a filled form, the SDK searches for the anchor, compares its position to the template position, and calculates the X/Y translation. That offset is applied to every field rectangle so the detection algorithm reads the correct locations regardless of how the paper was placed in the scanner.
Yes. The detection functions accept a sensitivity parameter that controls how much fill a field needs to count as marked. The SDK also returns a confidence array alongside the results, so you can flag uncertain detections for manual review.
A resolution of 200 to 300 dots per inch (DPI) is recommended. Below 150 DPI, the image quality may not contain enough pixel data for accurate detection, especially for small fields. Higher DPI improves accuracy but increases file size and processing time.
Yes. The SDK is a standard .NET library — loop through your scanned images, run the anchor search and mark detection on each one, and collect the results. There are no UI dependencies for processing, so you can run it in a background service, console application, or scheduled task.
OMR is available in Nutrient .NET SDK. It runs on any platform that supports the .NET runtime — Windows desktop applications (WinForms, WPF), Windows services, ASP.NET, and .NET console applications.
FREE TRIAL
Start extracting marks from scanned forms in C# in minutes — no payment information required.
An OMR SDK lets developers programmatically detect filled marks on scanned documents — bubbles, checkboxes, and ovals on exams, surveys, and forms. Nutrient .NET SDK provides the full OMR pipeline: template definition, anchor-based alignment, and mark detection with configurable sensitivity.
When selecting an OMR SDK, consider the shape types it supports, how it handles scan alignment, and whether it fits your deployment model.
OMR detects whether specific fields are marked — it answers “Is this bubble filled?” OCR recognizes text characters in an image — it answers “What does this text say?” They solve different problems but are often used together. Nutrient .NET SDK includes both OMR and OCR engines.
Nutrient’s OMR engine is part of a broader document processing SDK, so you get OMR alongside OCR, barcode reading, scanning, and image processing in a single library.
Three common issues affect OMR accuracy: low scan resolution (below 150 DPI), mark fields that are too small (leaving too few pixels for the algorithm), and scan-to-scan alignment differences. The first two are addressed in form design — scan at 200 to 300 DPI and make fields large enough. The third is handled by the SDK’s anchoring engine.
