ONNX anomaly detection inference: from maps to pass/fail

An exported anomaly model can run successfully and still produce the wrong pass/fail result. The deployment may interpret an anomaly map as a class score, apply different preprocessing, or compare values against a threshold from another score domain. This procedure helps you reproduce the original inference pipeline, verify each transformation, and validate decisions using known good and defective images before connecting the result to production equipment.

Decide what the exported model actually delivers

ONNX anomaly detection inference needs a complete decision pipeline, not just a model file. An exported graph might return a spatial anomaly map, an image score, or several outputs. Some exports include preprocessing and normalization; others leave those operations outside the graph.

Use this sequence rather than guessing a threshold:

1. Preserve the model, configuration, and decision metadata together.
2. Reproduce the reference input tensor.
3. Identify each output and its meaning.
4. Reproduce image-score aggregation.
5. Match normalization and threshold domains.
6. Compare reference and deployed decisions on fixed images.

Training quality and deployment parity are separate questions. If the original pipeline also fails to separate acceptable and defective parts, review anomaly detection training and early stopping. If the original pipeline works but the export does not, investigate parity before retraining.

Step 1: Preserve the inference contract

Start with the exporter's supported inference route for the exact software version that created the model. Obtain the runtime and supporting software through the developer's official distribution channels. Historical command names and options may not apply to a newer release.

Keep these artifacts together:

• Exported graph and any external weight files it requires.
• Preprocessing configuration, including color order and geometric transforms.
• Output names, shapes, data types, and documented meanings.
• Image-score aggregation and any map postprocessing.
• Normalization parameters and image-level threshold.
• Exporter version, runtime version, and execution-provider configuration.
• Reference images with saved intermediate results and final decisions.

Record file checksums so a model cannot silently become paired with another export's metadata. An image threshold without its score definition is incomplete configuration.

If the metadata is missing, recover it through the original supported export process. Do not estimate replacement parameters merely to make a few examples pass. A replacement threshold requires a separate calibration and validation exercise.

Step 2: Match preprocessing before comparing scores

Feed the same saved image into the original pipeline and the deployed pipeline. Compare their input tensors before interpreting any output differences.

Check geometry first: resize dimensions, aspect-ratio handling, crop location, padding, and interpolation. A stretched part and a padded part are different inputs, even when their final tensor dimensions match. Confirm whether preprocessing occurs inside the graph before repeating it outside.

Next check channel order, numeric range, normalization, layout, and data type. For example, a graph might expect a floating-point tensor with shape [1, 3, 256, 256]. That describes one image with three channels, but it does not establish channel order or pixel scaling. Inspect the actual export contract rather than assuming this example applies.

Where the reference uses channel standardization, reproduce its exact constants and operation order:

The divisor and channel statistics must come from the reference configuration. Dividing an already scaled image again can change every anomaly score without causing a runtime error.

Save tensor shape, minimum, maximum, mean, and a few selected values for comparison. A channel swap can preserve global statistics, so compare corresponding tensor elements too.

For live acquisition, keep exposure and gain changes outside this initial comparison. Verifying per-frame exposure and gain metadata helps distinguish changing image acquisition from changing model behavior.

Step 3: Inspect outputs instead of assuming class counts

Query the runtime for input and output names, shapes, and data types. Select outputs by their verified names rather than assuming the first output always contains the needed score.

An output shaped [1, 1, 256, 256] can represent one spatial anomaly score per location. It is not necessarily a vector of class probabilities, and the single channel does not mean there is only one possible decision. The image-level normal/anomaly decision may happen after the graph runs.

Confirm these details against the supported reference inference path:

• Does a larger value indicate greater abnormality?
• Is the output a raw map, normalized map, mask, or image score?
• Does the graph already perform smoothing or resizing?
• Is the map resolution different from the source image resolution?
• Does a separate output already contain the image-level score?

Do not apply a probability conversion simply because values look unfamiliar. Distance-based anomaly scores need not lie between zero and one.

A heatmap rendered for display is also not a numerical reference. Color scaling can make different score ranges look equally bright. Preserve the underlying floating-point arrays for comparison.

Step 4: Reproduce image-score aggregation

Use the original image-score calculation. A maximum over the anomaly map is one possible rule, but it is not a universal property of anomaly detection.

For a verified maximum-based pipeline:

The maximum is taken separately for each image. Flattening an entire batch into one vector would let the most anomalous item determine the score for every item.

The following Python example implements only that verified rule. Its input is one image's flattened map, already processed into the same score domain as the threshold:

from math import isfinite


def classify_one(flat_map, image_threshold):
    values = list(flat_map)
    if not values:
        raise ValueError("Empty anomaly map")
    if not isfinite(image_threshold):
        raise ValueError("Invalid image threshold")
    if not all(isfinite(value) for value in values):
        raise ValueError("Non-finite anomaly map")

    image_score = max(values)
    label = "anomaly" if image_score >= image_threshold else "normal"
    return image_score, label

Handle an invalid result through a defined hold, reject, or operator-review path, not an automatic pass.

If the reference uses a percentile, an average over selected locations, or a restricted inspection region, reproduce that instead. Changing aggregation requires recalibrating the threshold. Likewise, adding smoothing or excluding borders changes the decision pipeline, even if the model file stays unchanged.

Step 5: Keep normalization and thresholds in the same domain

A frequent mismatch is comparing a raw image score against a normalized threshold. The reverse mismatch is equally invalid. Determine where normalization occurs and whether the threshold has already been transformed.

For illustration, consider a fixed affine normalization:

Here, a and b are fixed calibration parameters, with b > a. This example is not a replacement for the export's documented normalization method. Some pipelines use another transformation or include additional processing.

Suppose the saved calibration values are a = 2 and b = 10. A defective image has raw score 7.6, and the raw image threshold is 6.8:

A normal image with raw score 5.2 becomes (5.2 - 2) / 8 = 0.40, below the normalized threshold. Comparing its raw score, 5.2, against 0.60 would incorrectly reject it.

Do not compute fresh minimum and maximum values independently for every image unless the reference explicitly does so. Per-image display scaling can make the hottest location reach the same displayed value in normal and defective images, destroying useful between-image magnitude information.

Also distinguish image thresholds from pixel thresholds. One classifies the whole image; the other identifies locations for a mask. The binary inspection preview procedure helps inspect thresholded regions, but a clean-looking mask alone does not validate the image-level decision.

Step 6: Validate numerical and decision parity

Build a fixed validation set that includes easy examples and difficult production cases. Include acceptable texture variation, small defects, border defects, reflections, and samples close to the decision threshold. Keep threshold-calibration images separate from final acceptance images.

For every image, record the reference and deployed results at corresponding pipeline stages:

Use absolute and relative differences when comparing arrays:

Choose tolerances from the model's numerical behavior and decision margin. There is no universal tolerance that guarantees equivalent decisions. Tiny score differences matter when an image lies very close to the threshold.

As a pilot example, suppose a set contains 30 acceptable images and 20 defective images. Rejecting 2 acceptable images gives 2 / 30 = 6.7% false rejects. Passing 1 defective image gives 1 / 20 = 5% false accepts. These small-set rates describe the pilot, not a production guarantee.

Require both pipeline parity and acceptable inspection performance. Identical wrong decisions are not sufficient. Use the software upgrade validation checklist when changing the runtime, exporter, or deployment environment.

Diagnose mismatches in the most useful order

Start with deterministic saved images before changing camera settings, thresholds, or hardware. Change one pipeline component at a time.

Do not treat processor utilization as proof that inference is correct or incorrectly configured. Check runtime execution logs for provider selection and fallback. Measure preprocessing, graph execution, postprocessing, and transfer time separately before optimizing.

A different score aggregation may eventually improve your application, but that is a new pipeline requiring validation. It is not a repair for unexplained export differences.

Choose hardware only after the pipeline is reproducible

Separate image acquisition from model execution. Area scan cameras provide an acquisition route for a host-based pipeline. Use the camera finder to narrow interface, shutter, and resolution requirements independently of the model's internal input size.

The LS-CMR-0166 is an acquisition candidate to evaluate against your imaging requirements. Confirm image format, driver compatibility, triggering, and the complete transfer path before selecting it.

For centralized processing, review vision controllers. The MV-VC2140-128G40-1T is a controller candidate, not a guarantee of compatibility with your exported graph. Verify operating-system support, runtime dependencies, execution-provider support, and measured application latency.

Smart cameras are an alternative when the inspection can run within a supported on-device workflow. Do not assume that an on-device inspection platform accepts arbitrary ONNX graphs or reproduces your external postprocessing.

The LS-SMC-0063 belongs in that alternative-workflow evaluation. Confirm supported deployment methods before treating it as a replacement for a host-based pipeline.

Release checklist and next step

Before connecting decisions to production handling, check the following:

• Model and metadata checksums match the approved release.
• Preprocessing matches the reference, including channel order and geometry.
• Output meaning and anomaly direction are documented.
• Aggregation operates on each image independently.
• Normalization and threshold use the same score domain.
• Image and pixel thresholds are not confused.
• Empty, invalid, missing, and late results have defined handling.
• Fixed-image parity and held-out inspection tests both pass.
• Each decision remains associated with its source image or part identifier.
• The previous validated release can be restored.

This inspection decision is not a machine safety function. Keep required safety controls independent of model output.

For acquisition planning, use the camera configuration entry point below. For deployment review, send the input contract, output shapes, preprocessing description, and parity results through applications support. Those details are more useful than a heatmap alone.