Separate NDT Screenshots from Source Measurement Records

Start with the purpose of the screenshot in the handover. It might illustrate the location of a reviewed indication, show an acquisition view or help a customer recognize a reported feature. Those uses require different context. Do not treat the image as self-explanatory simply because the person who created it understands the screen. State the observation or relationship the reader should take from it and identify any supporting evidence needed to verify that interpretation. A useful caption describes a specific view rather than claiming that the picture proves the entire examination was complete.

Separate illustration from the underlying technical conclusion. A screenshot can support an explanation without containing every input required to reproduce the analysis. The responsible reviewer should establish what the image is suitable for and whether the recipient also needs the source dataset, settings or another record. If the image is being used only as a navigation aid, say so. If it is part of the evidence for a reported result, retain the relationships that make that result traceable. The report preparer should not expand the image’s evidential role for visual impact.

Record the acquisition or source-result identity from which the screenshot was made. A filename such as indication-final.png does not establish which examination event, component or dataset it represents. Include the source file reference, relevant report item and any version needed to distinguish the accepted evidence from an earlier working copy. Keep those references stable through the handover. Renaming the screenshot for convenience should not break the connection to the data that produced it.

Evident’s open NDE file-format FAQ describes its acquisition files as structured data, illustrating why a native dataset and a screen image are different artifacts. The specific format depends on the equipment and software involved. Do not assume that a screenshot preserves the underlying channels, acquisition settings or interactive views. Confirm the actual source format and the receiving team’s requirements. This guide does not claim that NDT Connect imports or analyzes those native files.

A screenshot may be created during acquisition or during a later review. Record which event it represents and when that view was prepared if the project needs the distinction. A later capture date should not silently replace the examination date in the report. Similarly, a screenshot from a new review session may reflect different display settings without representing new field data. Identify that relationship so a recipient can understand whether the image documents acquisition, interpretation or a later explanation of an existing result.

Where several reviewers create images from the same dataset, retain enough identity to distinguish their views and the accepted review outcome. Do not rely on the most recently modified file being the approved illustration. Ask which image belongs to the report being prepared and what review record supports its use. If a view is superseded, keep the project’s controlled history rather than mixing it with the accepted set. The image log should make the chosen view easy to locate without pretending that file chronology establishes technical authority.

Describe the axes and orientation needed to interpret the displayed information. A reader may need to know the scan direction, physical datum, viewing side or coordinate convention. Include the unit and identify whether the image shows the full recorded range or a selected region. A cropped view can be useful for explaining a feature, but the crop should not imply that the surrounding area was examined or found acceptable. Keep the extent of the view distinct from the extent of the examination.

Check that a scale or coordinate reference remains intelligible after the image is resized for delivery. If the screenshot contains small labels that cannot be read, a larger source image or a separate explanatory reference may be necessary. Do not recreate a missing scale by estimating it from the picture. Obtain the relevant source context from the responsible person. A report author can improve the clarity of a caption, but should not invent geometric information or claim that a display pixel represents a verified physical dimension.

A selected display can be affected by zoom, color scale, gain presentation, filtering or other software controls, depending on the system. Record the settings that the responsible technical process identifies as necessary for interpreting the reported view. Do not prescribe one universal set for every method. The reader needs enough context to understand the selected display and its relation to the accepted result. Where a change affects interpretation, retain the review basis rather than treating it as a purely cosmetic adjustment.

Keep the source dataset unchanged through the project’s appropriate controls and identify any separately produced analysis output. An image edited for presentation should not be passed off as an untouched acquisition screen. If annotations, cropping or contrast changes are permitted for communication, retain the original image and make the nature of the presentation copy clear. Do not add or remove an indication, label or boundary in a way that alters the technical meaning. The review record should distinguish what the instrument or analysis software displayed from what an editor added for explanation.

An arrow, outline or callout can help a reader find a feature, but it also introduces an interpretive statement. Make sure each annotation is supported by the responsible review and is linked to the correct report item. Avoid drawing a boundary that looks like a measured indication extent when it is merely a visual highlight. If the annotation is approximate or illustrative, describe that purpose explicitly. The recipient should be able to distinguish a navigation aid from a dimension or classification recorded through the examination process.

Keep annotations legible without covering the evidence they are meant to explain. Use a separate caption or reference table when a dense set of callouts obscures the original display. Record the annotation version and the source image when the project requires review of the presentation. A changed callout can affect the meaning of a report even if the underlying screenshot remains the same. Check the image and caption together before issue rather than treating graphic preparation as unrelated to technical document control.

The source dataset identity and the component identity need a supported connection. A technically clear image can still be unusable if the recipient cannot determine which weld, tube, plate or location it describes. Link the view to the agreed component reference and the relevant examination event. If the image shows a local coordinate, identify the reference that relates that coordinate to the component. Do not infer the relationship from a similar-looking earlier image or a filename copied from another job.

NIST’s work on relationships between design, manufacturing and inspection information provides context for maintaining these links. For this practical task, the screenshot log should let a reviewer move from a report item to the view and then to its source evidence. The log is not a digital twin or an automatic asset-mapping service. It records the relationships that the project has actually established and leaves uncertain associations visible for clarification.

Consider a fictional encoded examination where the analyst supplies an overview image and a close-up view for one reported indication. The close-up is easier to read, but its crop removes the global scan reference. The report preparer retains both views in the supporting package and assigns separate image references. The overview establishes the selected region within the source view; the close-up illustrates the feature discussed in the report. The dataset, component reference and review record remain common links between the two images.

A later presentation copy adds an arrow to the close-up. The preparer records that it is an annotated copy and checks the arrow against the accepted review explanation. The report does not describe the arrow length as a measured indication size. When the customer asks for further analysis, the supplier provides the agreed source-data access rather than claiming the image contains all required information. This example is hypothetical and demonstrates documentary relationships only, not a real result, a method capability or a prescribed inspection arrangement.

Record the instrument or analysis system references that the report requires, using the actual equipment records for the examination. The equipment tracker can help organize identifiers and supporting documents. It does not verify that a particular screenshot came from that equipment or that the equipment was suitable for the task. Confirm those relationships from the source record. If the image was produced in a later analysis application, distinguish that software context from the instrument used to acquire the data.

Avoid copying a generic product name into every image reference when the evidence depends on a particular configuration or version. At the same time, do not overload a simple illustrative caption with unrelated equipment history. Identify what is necessary to understand and retrieve the view, then point to the controlled supporting record for more detail. The software and firmware change guide can help when a version change affects how a saved dataset or screenshot is interpreted.

Agree whether screenshots are delivered as separate files, within another controlled document or through the customer’s approved system. Keep the image index aligned with that delivery arrangement. NDT Connect’s reporting editor can hold filenames and contextual references as text; its image upload slots are for company and client logos. It does not provide a native NDE-image analysis workspace or automatically attach the original examination dataset. Use the actual project route for the supporting images and data, and make the references usable to the recipient.

The native-data handover guide addresses the wider transfer of acquisition files, while the file-manifest guide helps list the package contents. Keep this screenshot log focused on the meaning of each selected view. Verify that every referenced image exists in the delivered package and that its filename matches the report. A valid reference to a file that the customer never receives is still a handover gap, even if the report itself looks complete.

Review the image package as though you did not attend the examination. Locate the report item, find the referenced image and identify its source, orientation and intended observation. Check whether the caption distinguishes the view from the complete dataset and whether the relevant limitation is visible. If the explanation depends on an undocumented verbal briefing, add the missing context through the agreed report or supporting record. Keep the wording concise, but do not remove the very information that makes the picture interpretable.

Ask the responsible reviewer to confirm any statement that goes beyond navigation, such as a reported dimension or technical classification. A report preparer’s familiarity with image-editing tools is not authority to create that conclusion. If the source cannot support a requested claim, state the gap and obtain the appropriate evidence or decision. A clear image can still be insufficient for the recipient’s intended purpose. The useful response is to identify that boundary, not to imply that higher resolution or more annotations will supply missing technical information.

The image received by the customer may differ from the version viewed during preparation if a messaging service, document export or presentation step resizes it. Open the actual delivery copy and check the labels, scale, legend and feature discussed in the report. A recognizable overall picture is not enough if the decisive label is unreadable. Keep the accepted source image available and avoid successive resaving through several formats when the project can deliver a clearer reference copy directly. Record which version the report references so a recipient can request the correct file.

If a small display is needed in a summary, provide a usable reference to the full accepted image through the agreed package. Do not compensate for unreadable evidence by inventing a clearer-looking graphic that lacks the original source relationship. A separately prepared explanatory sketch may be useful, but label it as a sketch and retain its basis. The recipient should know whether it is viewing an acquisition display, an analysis view, an annotated copy or an editorial illustration. These distinctions help preserve the meaning of the image when it travels beyond the team that prepared it.

If a screenshot, caption or reference changes after issue, determine whether the change affects what the recipient understood. Replacing an image with another view of the same dataset can still alter the apparent extent or meaning of the evidence. Use the project’s controlled amendment process where required and preserve the earlier relationship. Do not quietly overwrite a file in the delivery package while leaving the report reference unchanged. The report amendment guide provides the broader correction framework.

Close the log by checking that every selected image has a supported purpose, source link, report relationship and appropriate limitation. Retain the accepted version through the agreed project process. The intended result is not a larger collection of screenshots; it is a smaller set of useful views whose meaning can be followed back to the evidence. That makes the report easier to review and gives a future reader a clear route to request further data when an illustration cannot answer the next technical question.