Read back Axis view geometry after a crop change

Bottom line: Read back and retain the returned view rectangle after a geometry change. Compare it with the intended scene instead of letting the client continue to display or calculate from the requested coordinates alone.

Source fact: documented behavior

Axis’s View Area API defines view subsections as virtual channels and expects their pixel coordinates to match the overview stream’s rotation and mirroring.

The documentation requires crop geometry to align with the canvas grid, usually 8 by 8 pixels, and describes seeking an optimal fit when the request cannot align on every side.

The geometry-change example advises updating local geometry from the response because the returned rectangle can differ from the submitted one.

What the source does not establish

Do not assume the usual grid size applies identically to every product or that an accepted crop preserves the operational image requirement. Confirm the intended canvas, orientation and supported view area. Keep crop geometry separate from channel enablement, privacy-region acceptance and measured recorded detail.

Applicability questions

• Which virtual channel and overview canvas define the requested rectangle?
• Do the client’s coordinates match the actual rotation and mirroring?
• How does the client update its saved geometry from the response?
• Which edge or target must remain visible in the accepted scene?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

DSE recommends reconciling submitted, returned and observed view geometry as three separate parts of a crop change.

1. Read the current view-area information and identify the exact channel, canvas and orientation. Record the approved scene boundary with a permitted reference image or marked task location. Prepare the requested rectangle in the documented coordinate system. Avoid using a rectangle from a different stream size as if it were already expressed on this canvas.
2. Apply an approved test geometry through the supported interface and preserve the full sanitized response. Compare the returned rectangle with the submitted values before updating the client’s local state. If they differ, retain both rather than rounding the returned values back to the request. Make the returned supported geometry the basis for the client’s subsequent display and review.
3. Inspect the resulting live view and the relevant recorded workflow with the operator. Check the required edges and targets, not just the center of the crop. For a proposed client exercise, include a supported request near a grid or aspect-ratio boundary and observe the actual returned fit. If the result misses the task, revise the approved geometry or design rather than concealing the difference in the client.

Verification and evidence

Retain the original, requested and returned rectangles with their canvas, channel and orientation. Keep a permitted resulting-view observation linked to the same change. Ask another reviewer to explain which coordinates the client now stores and why they may differ from the submitted request.

Repeat the reconciliation after an approved orientation or view configuration change. Record image-quality and privacy checks separately where required. The proposed exercise does not assert a universal rounding rule, an exact installed grid size or a successful crop on any customer camera.

Official references

• View Area API — Axis Communications; official VAPIX documentation.

Source review completed October 29, 2026. Recheck the official documentation and the deployed device’s capabilities before changing production settings.