OCR results visualization with side-by-side image grids

Opening a separate window for every OCR search makes comparisons slow and confusing. A labeled grid lets you compare the same character across images, or several characters within one image, without losing their relationship. This workflow is for inspection developers debugging recognition output. You will organize cached results, calculate tile positions, and draw overlays without changing the images used for recognition. For image capture and reading fundamentals, start with digital meter OCR.

Choose what each row and column means

For a small inspection batch, use one row per input image and one column per target character. Keep the target order fixed throughout the batch. With three images and three targets, the display contains nine tiles in one figure.

Each tile should identify the input image, target character, and number of matches. A tile without detections must still show its source image. Otherwise, an empty region could mean no matches, a missing file, or a rendering error.

Use stable image identifiers rather than row numbers alone. A row can move when you sort the batch, while an acquisition identifier should remain attached to its results.

Build a repeatable display pipeline

1. Load and retain each original image. Treat the acquisition array as read-only. Save any recognition preprocessing as a separate image with its own coordinate mapping.
2. Run recognition once per input image. Cache the recognized text, available confidence values, and bounding boxes. Searching several target characters should not require repeated recognition of unchanged pixels.
3. Define the target list explicitly. Decide whether matching is case-sensitive and whether targets represent characters, words, or patterns. Do not silently change these rules between columns.
4. Extract the matching boxes. Build a collection indexed by image and target. Store an empty collection when a search succeeds but finds nothing; represent processing failures separately.
5. Create the figure before the loops. Select an explicit axes object for every tile, then draw the source image and its matching overlays there.
6. Label and save the comparison. Record image identifiers, target labels, recognition settings, and the inspection recipe revision alongside the rendered grid.

For three images and three targets, this organization makes three recognition calls followed by nine target searches. Running recognition inside both loops would instead make nine recognition calls. The time saved depends on the recognition engine and image content, not just the call count.

Implement the grid with explicit axes

The plotting routine below uses subplot to create the grid. It assumes images and recognition results are already available; it does not run OCR or choose a recognition engine.

Prepare these inputs:

• images: a cell array containing the original image arrays.
• imageLabels: a cell array of image identifiers in the same order.
• targets: a cell array of character labels defining the columns.
• boxesByImageAndTarget: a cell array whose entries contain matching rectangles as rows of [x y width height].

Convert rectangles into the displayed image's coordinate convention before calling the routine. An entry with no matches can contain an empty array.

function fig = plotOcrGrid(images, imageLabels, targets, boxesByImageAndTarget)
    nRows = numel(images);
    nCols = numel(targets);
    fig = figure;

    for r = 1:nRows
        source = images{r};

        for c = 1:nCols
            tileIndex = (r - 1) * nCols + c;
            ax = subplot(nRows, nCols, tileIndex, 'Parent', fig);
            imshow(source, 'Parent', ax);
            hold(ax, 'on');

            boxes = boxesByImageAndTarget{r, c};
            for k = 1:size(boxes, 1)
                rectangle('Parent', ax, ...
                    'Position', boxes(k, :), ...
                    'EdgeColor', [1 1 0], ...
                    'LineWidth', 1);
            end

            label = sprintf('%s | target %s | matches %d', ...
                imageLabels{r}, targets{c}, size(boxes, 1));
            title(ax, label, 'Interpreter', 'none');
            hold(ax, 'off');
        end
    end
end

The explicit axes handle prevents annotations from landing on whichever subplot happens to be active. The routine draws graphics over the displayed image rather than inserting colored pixels into the source array.

Validate the inputs before rendering. Reject empty image lists, mismatched label counts, and box collections with incorrect dimensions. Also distinguish an unavailable recognition result from a valid result containing no matches. Display an error status for the former rather than reporting a misleading zero.

Work through tile indexing and pixel sampling

For row-major subplot ordering, calculate the tile index from the row, column, and total column count:

With three columns, row two and column three give:

This formula adapts when you add images or targets. Hard-coded subplot positions often create errors when the target list changes.

Display size and recognition resolution are separate quantities. Suppose a hypothetical image contains 2400 horizontal pixels across a 120 mm field. A character measuring 0.8 mm high would occupy approximately:

This estimate assumes a planar target, approximately equal horizontal and vertical sampling, and limited perspective distortion. Sixteen pixels is an example result, not a universal OCR acceptance threshold. Validate the required character size using representative fonts, surfaces, and defects.

Use the camera finder after establishing your required field and character sampling. The resolution calculator helps translate those requirements into an initial pixel count:

Shrinking that image into a small tile can make a readable character appear indistinct. Judge recognition inputs at native resolution before attributing poor-looking thumbnails to the camera.

Keep coordinates and overlays honest

Bounding boxes must describe the image underneath them. If recognition runs on a crop, its local coordinates need the crop offset before you draw them on the full image.

For a crop beginning at horizontal offset 100 pixels and vertical offset 50 pixels, a local box origin of 20 pixels and 30 pixels becomes:

This addition applies only when the crop has not also been resized, rotated, or geometrically corrected. Those operations require the corresponding inverse mapping. Consult camera image rotation when orientation changes are part of your pipeline.

Confirm whether your recognition API reports character boxes, word boxes, or line boxes. A word rectangle containing the target letter does not prove that an individual character was localized correctly.

Use thin outlines for inspection. Filled rectangles can hide the strokes needed to diagnose confusion between similar characters. Put long labels outside the recognition region, and avoid using color as the only indication of status.

For grayscale comparisons, apply a consistent display mapping across tiles. Independent automatic contrast stretching can make identical intensity differences look unrelated. Preserve higher-bit-depth source data separately; saving 12-bit camera images explains the storage distinction.

Choose the acquisition and processing architecture

The image grid is a diagnostic interface, not an OCR capability specification. Choose acquisition hardware for the image requirements, then confirm that the selected processing system can export the results needed by your display.

Smart cameras can place inspection processing at the device. Before selecting this architecture, verify the available recognition tools, image export, result fields, and supported software licenses.

The LS-SMC-0063 is a GigE smart camera. Confirm its applicable OCR and result-export capabilities for your application before ordering.

Area scan cameras suit workflows where acquisition and recognition software are selected separately. Check runtime compatibility, image format support, and access to character-level results rather than assuming every integration exposes the same information.

The LS-CMR-0166 is a 12 MP USB3 area scan camera with 4000 × 3000 resolution. It uses a rolling shutter, so evaluate motion effects during acquisition.

If the inspection uses vision controllers, confirm camera connections, recognition runtime support, and diagnostic image retention. Do not assume that displaying a grid on a development workstation proves deployment compatibility. The camera acquisition software compatibility guide helps separate acquisition support from downstream processing requirements.

Verify the grid before using it for decisions

Start with a small, manually checked dataset. Include an image with known matches, an image without the target, and an image containing several repeated instances.

Check these behaviors individually:

• Correct placement: every rectangle surrounds the intended character in the correct source image.
• Correct grouping: each row retains its image identity, and each column retains its target definition.
• No accumulation: updating a tile removes old graphics rather than leaving stale detections behind.
• No source modification: the acquisition arrays remain identical before and after rendering.
• Distinct failure states: recognition errors are not displayed as successful searches with zero matches.
• Consistent matching: case rules and character normalization match the inspection specification.

For live acquisition, attach a frame identifier to both the image and its recognition result. Delayed processing must not draw results from an earlier frame over the latest preview. The camera preview overlays guide covers related diagnostic display checks.

Keep acceptance decisions independent of whether a display window exists. Rendering failures should produce diagnostic faults, not silently change an inspection result.

When a single grid is the wrong view

A large grid can conceal the very differences you want to inspect. If character strokes become smaller than the display can show clearly, switch to fewer rows, paginated batches, or native-resolution character crops.

For repeated characters, include a match index or position alongside each crop. Otherwise, several identical labels can make it impossible to trace an ambiguous result back to its source location.

For continuous production, update a bounded set of tiles instead of opening new figures for every frame. Archive raw images and structured results according to your retention requirements; a screenshot alone cannot reconstruct the recognition input or processing settings.

The usual character-column layout is also unsuitable when reading order is the main question. In that case, show the complete recognized string and sequence positions alongside the source image.

Checks before ordering and the next step

Before committing to hardware or software, confirm:

• The smallest required character has adequate sampling across the full inspection area.
• Motion, focus, reflections, and exposure have been checked using representative parts.
• The runtime exposes the required text, boxes, status fields, and image identifiers.
• Recognition and display coordinate conventions have been reconciled.
• Original images remain available without baked-in overlays.
• The deployment license covers the required recognition and export functions.
• Diagnostic rendering can be limited without slowing the inspection path.

Start with the camera configurator when acquisition requirements are defined. If result export or deployment compatibility remains uncertain, send representative images and your required output fields through application support before choosing the inspection architecture.