A detector can accept a tensor with the expected element count and still see a distorted, rotated or incorrectly padded image. The problem usually starts when camera dimensions, image-library arguments and model shapes use different axis conventions. This matters when you move a trained detector into a fixed-aspect-ratio inspection station. You need a written input contract, a reproducible geometric transform and a way to verify detections against the original camera image.
Record the dimension contract before changing anything
Object detector input dimensions have no universal ordering across every interface. A tensor layout may place height before width, while an image-resize function requests width before height. Read each interface separately rather than carrying one convention through the entire pipeline.
Use explicit names such as input_height and input_width. Avoid passing an unlabeled pair between acquisition, preprocessing and inference code.
| Interface or representation | Example | Interpretation |
|---|---|---|
| Camera image dimensions | Width 1600, height 900 | A landscape image |
| Image array using HWC layout | [900, 1600, 3] |
Height, width, channels |
| Detector tensor using NCHW layout | [1, 3, 384, 640] |
Batch, channels, height, width |
| Detector tensor using NHWC layout | [1, 384, 640, 3] |
Batch, height, width, channels |
| Resize function argument | Interface-dependent | Confirm whether it requests width-height or height-width |
These are illustrative layouts, not requirements for every detector. Some inputs have different channel counts, additional inputs or other layouts.
Record the following beside the deployed model:
- Input name, layout, data type and permitted shapes.
- Channel order and numerical normalization.
- Resize policy, interpolation method and padding value.
- Padding placement and any alignment constraint.
- Output coordinate units and the inverse geometric transform.
The image preprocessing overview explains where resizing and other image operations fit. Treat their configuration as part of the model deployment, not as an interchangeable camera setting.
Separate training, export and inference settings
Training configuration describes how training images become model inputs. An export configuration describes the interface of the exported artifact. Inference configuration describes what your application actually sends. Similar parameter names do not prove that these stages use identical conventions.
Start with the preprocessing used during training. Determine whether it used square canvases, rectangular batches, cropping, stretching or aspect-preserving resizing with padding. Do not infer this from the original image dimensions alone.
Next, inspect the exported model's input metadata. For a fixed-shape input, the tensor supplied at runtime must match that interface. For a dynamic-shape input, confirm which axes are dynamic and which shapes the selected runtime supports.
Finally, inspect the tensor immediately before inference. Logging the camera frame size is not enough: preprocessing may already have changed its dimensions, channel order or data type.
As an illustrative alignment check, a model might require dimensions divisible by 32. A height of 384 and width of 640 meet that condition because 384 / 32 = 12 and 640 / 32 = 20. Use this test only when the model or runtime documents that requirement.
Keep geometric checks separate from numerical checks. The color normalization input checks cover channel scaling and normalization problems that can remain even when the tensor shape is correct.
Calculate resizing and padding explicitly
For aspect-preserving letterboxing, resize the source image until it fits inside the target canvas, then fill the remaining area with padding. Both source axes use the same ideal scale factor.
The rounding and distribution of padding must match the implementation. Centered padding typically splits each total between opposite edges. An odd total requires one edge to receive the extra pixel.
Consider a source image with width 1600 pixels and height 900 pixels. First, place it on a square canvas with width 640 pixels and height 640 pixels:
Now consider a rectangular canvas with width 640 pixels and height 384 pixels:
The useful image has the same dimensions in both cases. The rectangular canvas removes padding without shrinking the scene further.
| Property | Square canvas | Rectangular canvas |
|---|---|---|
| Target width × height | 640 × 640 | 640 × 384 |
| Resized scene width × height | 640 × 360 | 640 × 360 |
| Top and bottom padding | 140 pixels each | 12 pixels each |
| Canvas pixel count | 409600 | 245760 |
The reduction is (409600 - 245760) / 409600 = 40%. With batch size, channel count and data type unchanged, that also means fewer input tensor elements. It does not promise a matching reduction in inference time or total memory use.
Downsampling quality remains relevant even when the arithmetic is correct. Follow the antialiasing guidance for resizing and warping when fine edges or small defects must survive the reduction.
Map detections back through the same transform
A correct detector output can appear misplaced when the application reverses preprocessing incorrectly. Store the transform with each image rather than rebuilding it from assumptions later.
For an ideal uniform scale and padding, continuous image coordinates transform as follows:
In the square example, a source point at x = 1000, y = 600 becomes:
Reversing the transform gives (400 - 0) / 0.4 = 1000 and (380 - 140) / 0.4 = 600.
With the rectangular canvas, the same point becomes x = 400, y = 252, because the top padding is only 12 pixels. Reusing the square padding offset would place the detection incorrectly.
Confirm whether outputs are normalized coordinates, model-input pixels or coordinates already restored by a postprocessing wrapper. Applying the inverse transform twice creates another alignment error.
For rounded resize dimensions, retain the actual dimensions and offsets used. Match the preprocessing library's coordinate convention, including any pixel-center treatment. Cropping requires a crop offset as well; stretching requires separate horizontal and vertical scale factors.
Validate with a non-square diagnostic image
A square test image cannot expose every height-width mistake. Use an asymmetric test image before evaluating detection accuracy.
- Create a landscape image with a visible top marker, a left-edge marker and a circle near one corner. Keep its orientation unmistakable.
- Run the production preprocessing path, not a separate demonstration script.
- Log the original dimensions, resized dimensions, padding offsets and final tensor shape.
- Save a viewable copy of the actual model input, reversing numerical normalization only for display.
- Check that the top remains at the top, the circle remains circular and padding appears on the expected edges.
- Pass known coordinates through the forward and inverse geometric transforms. Check corners and interior points, not just the center.
- Run representative inspection images through the exported model and compare restored detections with the source images.
The diagnostic image verifies geometry, not model quality. Use real examples to evaluate missed detections, false detections and localization afterward.
Record image identifiers with the preprocessing metadata. Otherwise, a correct overlay drawn on the wrong captured frame can look like a coordinate error. Include these checks in the broader camera-to-host inference deployment plan.
Choose acquisition independently of the model canvas
A rectangular detector input does not require a camera with exactly the same pixel dimensions. Choose acquisition resolution from the field of view and smallest feature you must detect. Then calculate what remains after preprocessing.
In the worked example, a feature spanning 10 source pixels spans only 10 × 0.4 = 4 resized pixels. Whether that is adequate depends on the task and must be validated. Removing padding does not restore detail already lost through downsampling.
Compare area scan cameras through the camera finder using your acquisition requirements. Interface compatibility, capture timing and usable image detail remain separate from the detector's tensor layout.
For a USB3 acquisition candidate, inspect the LS-CMR-0166.
- Sensor format
- 1/1.7"
- Interface
- USB3
- Resolution
- 12 MP
- Shutter
- Rolling
For a GigE acquisition candidate, inspect the LS-CMR-0053.
- Sensor format
- 1/1.7"
- Lens mount
- C-mount
- Interface
- GigE
- Resolution
- 12 MP
These are capture candidates, not claims that inference runs inside either camera. Verify acquisition software support and measured timing for the complete application. Begin the camera configuration process with the inspection requirements rather than the model's canvas size alone.
Know when rectangular inputs are the wrong change
Removing unnecessary padding is useful when the source aspect ratio is stable and the exported model supports the proposed shape. It is not a substitute for validation.
Keep the existing input shape when the deployment runtime requires it or when the validated model package specifies it. A smaller tensor is not helpful if it introduces unsupported operations or changes detection quality beyond your acceptance limits.
Avoid stretching the scene merely to fill a rectangular canvas. Stretching changes object proportions. It can be appropriate when it matches the trained pipeline, but it should not appear accidentally during deployment.
Cropping is another distinct decision. It may preserve more detail in the retained area, but it removes scene content. Check objects near every crop boundary and account for the crop origin when restoring coordinates.
Even unchanged useful-image dimensions do not guarantee identical predictions after changing the surrounding canvas. Validate edge objects, small objects and low-contrast examples. Measure inference time and end-to-end latency separately before accepting a performance claim.
Use a release checklist for the input contract
Before releasing the inspection recipe, confirm these items:
- Axes: every dimension pair has documented height and width meanings.
- Layout: the supplied tensor matches the model's channel and batch axes.
- Geometry: resize, crop and padding match the intended deployment pipeline.
- Numerics: channel order, data type, normalization and padding value are verified.
- Compatibility: the exported model and runtime accept the exact proposed shape.
- Coordinates: restored detections align across the image, including its edges.
- Quality: representative images meet defined detection acceptance limits.
- Timing: measured acquisition-to-decision latency meets the inspection requirement.
- Traceability: the model artifact and preprocessing configuration are versioned together.
Keep the diagnostic image and expected transform alongside the deployment package. Re-run them whenever preprocessing, export settings or runtime versions change.
For the next step, use the camera finder to establish acquisition requirements, or contact the applications team with your source dimensions, target tensor shape and smallest inspection feature.
Questions
Are object detector input dimensions height-first or width-first?
There is no single ordering shared by every interface. Tensor layouts commonly identify height before width, while some image functions request width before height. Inspect the model metadata and each preprocessing function separately. Use explicitly named variables so an unlabeled dimension pair cannot silently change meaning.
Does the camera resolution need to match the detector input?
A camera image can be resized and padded to the detector's required canvas. What matters is preserving enough useful detail and applying the intended geometric transform. Choosing matching dimensions may simplify preprocessing, but it does not replace checks for layout, channel order, numerical normalization and detection quality.
Will removing padding make inference faster?
Reducing padding can lower the input element count when the useful image keeps the same scale. Actual speed depends on the exported model, runtime and execution hardware. Compare measured latency and detection quality using the exact proposed shape before accepting the change.
Why are detection boxes shifted after changing the input shape?
Check the resize scale, crop origin and padding offsets saved during preprocessing. Also establish whether the inference wrapper already restored coordinates to the original image. Applying an inverse transform twice, or using offsets from a different canvas, can displace otherwise valid detections.
Does a dynamic export accept every image size?
No. A dynamic declaration permits variation only within the model and runtime's supported behavior. Some axes may remain fixed, and certain dimensions may violate operation or backend constraints. Validate the exact deployment shape rather than relying on the dynamic setting alone.

