Inspection images should be accepted with an agreed display orientation and annotation convention, not merely because the files open. For a UG32 proposal, trace a non-sensitive test image through export, browser review, annotation, and final report. Confirm that every reviewer identifies the same feature in the same view before treating an on-screen mark as inspection evidence.

Two reviewers, one file, different top edges

Consider a hypothetical review meeting. One person points to a defect near the upper edge of an image, while another sees the relevant structure along the left edge. Both may be looking at a file with the expected name. If the discussion immediately turns to the inspector's judgment, the team can miss a simpler unresolved issue: it has never agreed which displayed view is authoritative.

This article concerns the delivery and review contract. It does not assert that UG32 uses a particular camera, writes a particular metadata tag, or includes an inspection platform. Those details depend on the proposed configuration and software. The buyer's first job is to name the review chain and ask the supplier to demonstrate it.

Distinguish image orientation from an edited image

The MDN reference for CSS image-orientation explains that from-image uses EXIF information to orient an image. The none value does not apply additional orientation correction, subject to the documented security limitations. MDN also distinguishes that correction from other transformations. This is a browser behavior reference, not evidence about a specific aircraft camera or inspection application.

For procurement purposes, ask the supplier whether the agreed upright view is represented by metadata, by a processed image, or by a viewing application's behavior. Then ask what the next system receives. Do not ask a reviewer to guess from appearance whether a file has been changed. The supplier should be able to identify the source image, any derived version, and the rule that governs display.

There may be a legitimate reason to create a normalized review derivative. There may also be a legitimate requirement to retain the original capture file. The contract should say which artifact is preserved, which one is annotated, and how they are linked. Calling both files original invites confusion when a customer later asks which image supported an observation.

Describe the chain before buying the package

Draw the review path as a short list of named steps. For example: proposed image export, receiving storage, browser viewer, annotation tool, report generator, and archive. This is an illustrative structure, not a prescribed UG32 workflow. If one step is unknown, keep it visibly unresolved rather than filling it with the software a salesperson happens to recognize.

At each boundary, identify the person responsible for checking the handover. A camera supplier may not control a customer's report template. A report vendor may never see the capture files. The buyer needs a practical owner for the end-to-end demonstration even when several organizations supply the components.

Use a test that can reveal the mistake

A symmetrical photograph is a weak orientation test because several views can look plausible. Our editorial recommendation is to use a de-identified test image with distinguishable corners and an unmistakable feature. A corner marker can expose a rotation or mirror reversal before anyone trusts an inspector's annotation. This is a proposed review exercise, not a claim that a customer has encountered a particular failure.

Have the receiving reviewer identify the same feature after each step in the agreed chain. Record the expected corner positions in ordinary language so a procurement observer can follow the result. Where the workflow creates derivatives, retain the relationship between them. The purpose is not to generate a large test suite; it is to remove ambiguity about the image that carries the decision.

Do not test with sensitive asset imagery merely because it is convenient. A purpose-made, harmless sample can exercise the display path without disclosing a customer's infrastructure. Any test file must be clearly separated from operational evidence so it cannot later be mistaken for a genuine inspection capture.

Annotations need their own agreement

An annotation is more than a colored circle. Ask what its position refers to: the source image, the displayed derivative, a cropped view, or a page in a report. Ask how the origin and measurement units are defined. The buyer does not need to design a coordinate system, but the supplier should document the one its proposed workflow actually uses.

Include an ordinary change in the demonstration, such as reopening the saved review or exporting the report using the agreed template. If the project expects several viewing layouts, name those layouts in scope. Avoid promising that an annotation will survive every imaginable transformation; test the paths the customer intends to purchase and record the limits of that evidence.

If the mark moves or the feature cannot be identified, do not let the meeting close with an undocumented manual adjustment. Preserve the sample, the observed result, and the software versions. Assign the discrepancy to an owner and repeat the affected handover after correction. This creates a useful acceptance record without attributing blame before the cause is known.

A simple pass condition is better than visual confidence

Agree the pass condition before the demonstration: the receiving reviewer can identify the expected feature, the saved mark refers to the agreed image version, and the final report preserves that relationship. Add any project-specific tolerance only with the responsible inspection specialist. A commercial writer should not invent a pixel tolerance or a defect measurement criterion.

Separate display acceptance from inspection competence. A perfectly oriented picture does not establish that a finding is correct, that a feature was adequately resolved, or that the inspection meets a required standard. Conversely, a skilled inspector should not have to compensate silently for an undefined export process. Both technical interpretation and evidence handling deserve explicit ownership.

A short acceptance note can list the sample, the tools and versions tested, the intended feature, the outcome, and any excluded paths. That is more actionable than a statement that images looked fine during a demonstration. The note should make sense to the person who receives the project after the original participants have moved on.

Related handover questions should remain visible

If the inspection package also includes editable GIS data, check the GeoPackage release and recipient-copy boundary separately. The fact that an image review works does not establish that the GIS database contains the agreed final edits. Treat these as distinct deliverables even when they arrive in the same transfer folder.

For teams purchasing classroom support, the ground-learning transfer checklist suggests another useful distinction: recognizing a rehearsed example is not the same as explaining an unfamiliar but equivalent case. A training demonstration about review evidence should assess the intended judgment, not just familiarity with one screenshot.

What a UG32 inquiry can reasonably ask

Use the UG32 product listing to identify the aircraft under discussion, and the VTOL and fixed-wing collection to frame the broader configuration inquiry. Neither link establishes a particular image format, sensor, annotation license, integration, or inspection qualification. Request those items explicitly if they are part of the proposed purchase.

A well-scoped inquiry distinguishes the aircraft, any proposed imaging payload, the export process, and the customer's review tools. Ask which party can demonstrate the whole chain and which parts need a separate specialist. If the supplier can only confirm the aircraft component, keep the remaining workflow questions open rather than describing the package as turnkey.

Resolve the practical objections

For a phased purchase, price the review demonstration separately from routine inspection production. Name the sample owner, the receiving reviewer, and the person authorized to accept a discrepancy resolution. If a report tool is selected later, retain that as an open dependency. This helps a buyer compare offers fairly: a supplier that has demonstrated only an export should not receive the same workflow credit as one that has shown the agreed final report. Equally, a narrower supplier should not be blamed for a customer-controlled step excluded from its quotation.

Can reviewers simply rotate the picture? They may be able to change a view, but that does not settle the identity of the annotated artifact or the convention used by another system. Decide how such changes are recorded before relying on them.

Does identical file content settle the issue? It answers a different question. The acceptance exercise still needs to show how the agreed review chain presents that file and places the associated mark.

What should be sent for a first discussion? Share the names of the receiving tools, the proposed export route, and a de-identified sample description through the UNITED UAV inquiry page. Ask for a bounded orientation and annotation demonstration, with aircraft supply and software or service commitments itemized separately.

Technical reference checked 13 October 2026. Examples and acceptance suggestions are editorial analysis, not a documented inspection case or a guarantee of third-party software behavior.