An inspection annotation needs an image identity and a coordinate convention. A point measured on the stored pixel array is not necessarily the same point on the upright photograph a viewer displays after interpreting EXIF orientation. For visible-light photos delivered on a UVH2 inspection project, retain the original, identify any normalized derivative, and verify a recognisable landmark in the actual receiving application. Do not apply the same transformation to a thermal frame without separate evidence of the relationship.

The right window on the wrong floor

Imagine a technician marking a damaged window seal on a portrait-oriented facade photograph. The report looks correct on the analyst's laptop. In the maintenance system the image still looks upright, but the marker now sits on a neighbouring window. The field supervisor cannot tell whether the report has identified another defect or simply displayed the right finding in the wrong place. Sending the same screenshot again will not resolve the underlying disagreement.

The issue may have nothing to do with the aircraft's position. The analyst and maintenance application could be attaching the same numeric pair to different representations of the picture. One may use the original raster as stored. The other may first honour an orientation instruction, or may receive a derivative whose pixels have already been transposed. A visually plausible photograph is not proof that a separate annotation used the same frame of reference.

Ask for three items before requesting a repeat visit: the original image file, the exact file or preview to which the analyst attached the mark, and the annotation record as interpreted by the recipient. Keep them distinguishable. A JPEG downloaded from a report might be a reformatted copy rather than the original capture, even if its filename happens to be identical. The file and the convention together are the evidence.

What the orientation operation does

The Pillow ImageOps.exif_transpose documentation provides a concrete software example. Its EXIF transpose operation uses a non-default orientation instruction to transform the image accordingly and removes the orientation data. This is a useful reference for specifying a normalization step. It does not mean every viewer implements the same workflow, every file contains the tag, or that any particular UVH2 camera exports a given orientation value. Inspect the actual data delivered for the project.

A workflow can legitimately preserve stored pixels and interpret the metadata at display time. Another can write a normalized derivative and describe its pixels directly. Problems arise when a marker created in one representation travels with the other but the relationship does not travel with it. It is equally unhelpful to transform everything indiscriminately: a derivative already normalized should not silently be treated as an untouched original with the same pending operation.

Use a small paper exercise to explain this to a non-specialist. Draw a rectangle wider than it is tall and mark a corner with a triangle. Put a dot partway down one short side. Turn the sheet upright and ask someone to locate the dot using the old distances from the top and left edges of the desk. The paper contains the same dot throughout. The numbers only locate it once the person knows which edges and orientation gave those numbers meaning.

Write the annotation contract before the first review

Name the image used for marking. Record its dimensions, file identity or checksum, whether it is original or derived, and the coordinate origin and units used by the annotation system. State whether the positions are pixel indices, distances from an edge or normalized coordinates. Do not assume that a pair between zero and one is safe across different displays: it still has a reference frame, origin and orientation.

Define the geometry too. A defect might be represented by a point at its centre, a rectangle surrounding it or a polygon traced along an edge. The transformation for a rectangular region must preserve the intended location and extent; moving only the origin while leaving the width and height untouched can give an apparently reasonable but wrong box. An acceptance sample with only a central point will not expose many of these errors.

Record what other operations happened between files. A crop changes the origin of the derivative; a resize changes the coordinate scale; a rotated display can change the relationship of width to height. Orientation normalization alone is not a general correction for all three. Ask for the actual sequence rather than accepting “we rotated the image” as a complete specification. The buyer does not need to prescribe code to require an unambiguous result.

Build a sample that can fail visibly

Choose a non-square image of a clearly asymmetric subject. A building elevation with a service door at one side and a distinctive gutter joint near the opposite edge is more informative than a uniform wall. Mark one feature off centre and a second near a different edge. Record their identities in words as well as in coordinates. That way, even a reviewer unfamiliar with the software can recognise a mirror or quarter-turn error.

Run the sample through the same path as the deliverable: from original to analysis application, from annotation export into the owner's management system, and finally into any report given to a field worker. Test the editable mark as well as the rendered overlay. A flattened screenshot can look correct while the underlying coordinates, the part that the maintenance database will reuse, remain wrong. Conversely, a distorted report may be a presentation defect even when the stored coordinates are correct.

Add a second input that is already upright according to the agreed convention. If the recipient transforms every file on import, the control image may reveal a double correction. Include a file without usable orientation metadata where that condition occurs in the buyer's real workflow. Agree whether the supplier rejects it, qualifies it or establishes orientation from separate evidence. A guessed correction without a record simply replaces one unverified assumption with another.

Treat an RGB-to-thermal transfer as a separate question

A visible-light image and a thermal image can show the same facade without placing every architectural feature at the same pixel location. The transformation that makes a visible photo upright says nothing by itself about sensor alignment, different fields of view or the scene geometry. Do not copy a marker into a thermal file merely because it now falls on an upright display. Request the evidence required for the intended association.

The contract can use different precision levels for different decisions. A manager may only need a link saying that two records depict the same elevation. A technician asked to inspect a specific joint needs a more exact identification. State whether the delivered relationship is an image pair, a manually matched landmark or a validated geometric mapping. Buyers should not get a promise of the strongest interpretation when the evidence supports only the weakest.

Keep the thermal source unchanged unless the actual project method explicitly specifies an approved derivative and its purpose. A visible-photo orientation example is not a recommendation for manipulating radiometric content. If the supplier cannot substantiate a proposed cross-image marker, qualify or omit that transfer while preserving the independently valid visible-light observation. It can still be useful to the maintenance team when properly identified.

What to ask when comparing inspection packages

The UVH2 fixed-wing VTOL aircraft is listed for mapping, land surveying and thermal inspection. That product identity makes the handover question relevant, but it does not establish a particular image format, annotation integration, accuracy or included software. Ask for configuration details and a representative export appropriate to the quoted service. Compare available options in the VTOL and fixed-wing aircraft collection on the basis of the actual deliverable rather than an assumption about what a camera name guarantees.

If findings move from an asset register into a report, verify the observation-to-configuration join. A key relationship can duplicate or misassociate findings even after image coordinates have been corrected. Where defects must be assigned to one bank of a corridor, define the required bank of a one-sided corridor strip. These are independent tests: the right mark on the right photo may still be attached to the wrong asset or physical side.

Give the field supervisor a decision they can use

Write the acceptance result in terms of the named feature, not just the success of an import. For example, the maintenance viewer and exported work order both identify the same upper hinge on the same service door, using the approved derivative, while the archived original remains retrievable. If the annotation lands elsewhere, record the source and destination files, their dimensions, orientation handling and observed mismatch. That lets the supplier reproduce the problem without commissioning another flight.

Keep a small human-readable field label as a backstop: building, elevation, floor and a recognisable fixture where appropriate. It should not replace the image coordinates, but it lets a supervisor report a meaningful inconsistency rather than quietly following the wrong mark. For sensitive sites, agree how those identifiers are redacted in material distributed beyond the maintenance team.

A useful UNITED UAV configuration inquiry includes a sample annotation format, the receiving software, the intended use of edits, and a clear distinction between visible and thermal requirements. Ask the bidder to return a small original-and-derivative example with the marks attached rather than a slide showing that it can open an image. The test is whether the next person can locate the same feature after the photograph leaves the system in which it was marked.