Getting OmniScan and EPOCH Data Into a Client-Ready Inspection Report

Decide the deliverable before you open the file

The mistake that costs the most hours is starting from the acquisition file and asking what can be done with it. Start from the other end. Write down exactly what the client receives: a cover sheet with contract and procedure references, a technique or calibration record, an indication table with location and sizing, representative imagery, an acceptance statement against the governing code, and a Level II or Level III signature. That list is the specification for everything upstream.

Once the deliverable is fixed, each element traces back to a source. The indication table comes from the analysis software or from a parsed dataset. Calibration and technique parameters live inside the acquisition file and inside your procedure library. Images come from the analysis view. The acceptance statement comes from a human reading the code. Only two of those four are automatable, and knowing which two prevents you from buying a tool to solve a problem it cannot solve.

This ordering also decides how much file-format work is worth doing. If the client accepts an OmniPC HTML report with a cover sheet stapled on, the whole problem collapses to a formatting exercise. If the client wants tabulated thickness grids, trend comparison against a previous outage, or data loaded into an integrity database, you need the numbers themselves, and the format question becomes the project.

What each OmniScan file format actually carries

An OmniScan acquisition file is not a report and was never intended to be one. It is a dense record of the inspection: the beam configuration, the gates, the encoder positions, the calibration state, and the amplitude and time data for every focal law at every scan position. That richness is why the files are large, and why the same file can be reanalysed years later with different gates and different sizing criteria without going back to the weld.

Three formats matter in practice. The .opd file belongs to the MX2, SX and MXU 4.x generation and is the format most existing archives are stored in. The .odat file is OmniScan X3 acquisition data, the format WeldSight is built around. The .nde file is the Open File Format NDE, written by OmniScan X3 and X3 64 units running MXU 5.11 onboard software and later.

Evident is explicit that conversion between these formats is not supported. That single fact shapes fleet strategy more than any software choice. A company running mixed-generation OmniScans will be running two or three analysis paths in parallel, and any reporting pipeline has to accept that rather than assume a single normalised input. Plan the pipeline around whichever format your newest instruments write, and keep the legacy path alive for archive retrieval.

The .nde open file format removed the biggest blocker

For most of the phased array era, getting numbers out of an OmniScan file meant using Evident software or licensing a development kit. The Open File Format NDE changed that. Evident built .nde on HDF5, the open hierarchical data format, with a JSON descriptor layer, and states plainly that any software capable of opening and reading HDF5 or JSON files can also open .nde data. Files can be accessed without proprietary Evident software.

The practical consequence is large. A Python script using h5py, or a MATLAB session, can walk the file structure, pull the amplitude arrays and the acquisition parameters, and hand both to a reporting engine. That makes automated indication tables, batch thickness grid generation and integrity-database ingestion into ordinary engineering work rather than a vendor negotiation. It also means archived data stays readable independent of any single vendor's software roadmap.

Two cautions apply. First, readable is not the same as self-explanatory: you still have to learn the group and dataset layout before the numbers mean anything, and that is a real piece of work. Second, version compatibility is tracked per MXU release. Evident's OpenView SDK release notes, for example, record version 1.1.98.0 adding compatibility with OmniScan X3 MXU 5.17 .nde data files. Pin your instrument firmware and your parsing library together, and revalidate after either changes.

Legacy .opd and .odat still need vendor software or the SDK

Most companies with a decade of phased array history are sitting on .opd archives, and those files are not open. The supported routes are OmniPC for analysis and reporting, and the OpenView SDK for programmatic access. Public ndt.net forum threads asking how to convert .opd to raw data are long-running precisely because there is no sanctioned conversion path, and any workaround you find in a forum is unvalidated for code work.

The OpenView SDK is the honest answer for anyone who genuinely needs bulk access to legacy files. It is a development kit, which means a C++ or C# developer, a compatibility matrix to respect, and a test suite proving that what you extracted matches what OmniPC displays. That last step is not optional. If your extracted amplitude does not reproduce the analysis software's reading on a known reference, you cannot put the output in front of a client.

For .odat, WeldSight is the intended path. Newer MXU and OmniPC versions can open earlier acquisition files, but Evident notes that newer analysis features may not function with them. Treat that as a hard constraint on reanalysis campaigns: a file acquired under an older software generation may not support the sizing tools your current procedure calls for, and you need to know that before you promise a client a re-evaluation.

The C-scan CSV export, and what it leaves behind

The fastest route from OmniScan data to a numeric deliverable is the C-scan CSV export, and it is under-used. In OmniPC you right-click the C-scan window; on an OmniScan running MXU 4.2 or later you press and hold it. Select Export, and a CSV is written to the computer or to the SD card. Evident describes the output as containing every single data point from the inspection alongside the inspection information.

That file is immediately useful. Dropped into Excel, conditional formatting turns a thickness C-scan into a readable corrosion map in about a minute. Position, average thickness, minimum thickness and the area below a threshold all fall out of ordinary spreadsheet functions. The same file feeds pipeline burst-pressure calculators and fitness-for-service tooling without any transcription step, which removes the single largest source of reporting error.

Be clear about what does not come with it. The export is scoped to the C-scan view, so full A-scan waveform arrays are not in the file. Gate settings, wedge and probe details and the calibration record still have to be carried across from the setup or the analysis software. The CSV is a numbers pipe, not a complete inspection record, and a report built only from it will fail a document review.

EPOCH 650 and conventional UT take a different path

Conventional flaw detection and thickness work never had the format problem, because the data volume is small enough to stay tabular. The EPOCH 650 carries an onboard datalogger for calibration and inspection files with up to 100,000 points of memory, and saved data exports as .csv or .xml directly. GageView Pro provides the PC-side route, moving thickness or amplitude data to Excel, Word or similar programs over the USB client port.

This makes thickness survey reporting the easiest automation win in most NDT shops. A CML list goes out to the instrument as a file and ID structure, readings come back in the same structure, and a template joins them to previous readings to produce remaining-life and corrosion-rate columns. Nothing about that requires an SDK, and a competent Excel or Python build does it end to end.

The EPOCH 650 also records up to eight minutes of live A-scan at 60 frames per second, reviewable on the instrument or exported for PC review. That is evidence, not report data, but it changes what you can defend later. When a client disputes an indication call, a recorded A-scan sequence with the calibration file attached settles the argument in a way that a static screenshot does not.

Where DICONDE fits, and where it does not

DICONDE is the standard people reach for when they want vendor-neutral inspection data, and it is frequently misapplied. It is defined in ASTM E2339, Standard Practice for Digital Imaging and Communication in Nondestructive Evaluation, and it is a harmonisation of NDE imaging with the NEMA DICOM standard used in medical imaging. Its purpose is to preserve the technique parameters alongside the image data so that both survive changes in NDE technology.

Its strength is archival and cross-modality viewing. The standard is written so that CT, CR, ultrasonic, infrared and eddy current data can be displayed on a single conformant workstation regardless of the acquiring modality. For a company running digital radiography alongside other methods, that is a genuine long-term asset-integrity advantage, and it is why DICONDE dominates in DR and CT environments.

What DICONDE is not is a reporting format. It carries the image and the acquisition parameters; it does not carry your indication table, your acceptance criteria or your signature block. Nor is it the native output of an OmniScan. Treat DICONDE as the archive layer beneath your reporting layer, not as a substitute for it, and do not let a client specification that names DICONDE be read as a requirement your phased array fleet has failed to meet.

The four practical routes from instrument to client PDF

Route one is the vendor report. Generate the indication table in OmniPC or on the instrument, add comments and images, output HTML, print to PDF, attach a cover sheet. It is fast, it is defensible because the numbers are the analysis software's own, and it is inflexible. Companies whose clients accept it should stop here, because every alternative costs engineering time to gain formatting control they may not need.

Route two is CSV plus a template. Export the C-scan CSV or the EPOCH datalogger file, load it into a controlled Excel or reporting-engine template that already contains your cover page, procedure references and acceptance logic, and paste in analysis screenshots. This is where most mid-sized shops land. It removes transcription error, it keeps report branding under your control, and it needs no developer.

Route three is a programmatic pipeline against .nde. Parse the HDF5 file, extract indications and parameters, and render the report from a template engine with the images attached. Route four is the same idea against .opd or .odat through the OpenView SDK, which costs materially more effort. Route three is worth building when report volume is high and formats are standardised; route four is worth building only when a legacy archive has to be reprocessed at scale.

What no tool does for you automatically

No software decides whether an indication is rejectable. Acceptance is a judgement made by a qualified individual against a governing code and a written procedure, and every credible workflow keeps a human in that position. A reporting tool can pre-populate the amplitude, the depth, the length and the position, and it can flag values against thresholds you configured, but the accept or reject call and the signature that follows are personnel actions, not software actions.

No software reconstructs missing setup information either. If the acquisition file was saved without the correct probe, wedge, weld geometry or calibration block details entered, no downstream parser invents them. The cheapest quality intervention in the whole chain is enforcing complete setup metadata at the instrument, before the scan, because everything downstream is a copy of what was entered there.

And no import path fixes a bad scan. Missing data from lost encoder coupling, insufficient coverage of the required volume, or a calibration that drifted mid-shift will still be missing after the smartest parsing in the world. WeldSight's analysis dashboard reporting missing-data statistics exists because this is a real and frequent failure. Automation multiplies the quality of the data you acquired; it does not raise it.

Build the pipeline in-house or buy it

Building in-house is genuinely viable now that .nde is HDF5-based. A single competent Python developer, a documented file layout, and a validation set of files with known OmniPC readings will get a working indication-table extractor in weeks rather than months. The ongoing cost is what surprises people: firmware updates, new instrument generations, new client report formats and staff turnover all land on whoever wrote the script.

Buying shifts that maintenance burden but introduces a fit question. Ask any vendor exactly which formats they ingest, at which MXU versions, and what happens to your .opd archive. Ask whether their report templates are editable by your Level III or only by their support team. Ask whether reports can be produced and signed offline at a plant with no connectivity, because a great deal of NDT work happens inside facilities where phones are prohibited.

Atlantis builds the reporting layer for NDT service companies around this exact chain — ingest from exported CSV and HDF5-based .nde data plus captured imagery, method templates aligned to ASNT SNT-TC-1A written practices and ISO documentation requirements, offline mobile capture, and configurable client report formats — and integrates it with an Odoo-based ERP so certification, calibration and invoicing sit behind the same record. It is affordable, accessible and fully customisable, and it is scoped per company. Request a demo or a quote at /contact or info@atlantisndt.com, and bring three real files with you so the fit question gets answered with your data.

A short checklist before you commit to a workflow

Inventory your instruments by MXU version, not by model name, because the format boundary sits at MXU 5.11 for .nde and MXU 4.2 for the C-scan CSV export. Count how many of your units fall each side of those lines. That number tells you whether you are building one pipeline or two, and it is the single most useful piece of information in the whole exercise.

Take three representative jobs — a weld PAUT job, a corrosion mapping job, a conventional thickness survey — and walk each one end to end by hand, timing every step. Most companies discover that the expensive step is not data extraction at all but assembling the cover sheet, chasing procedure revision numbers, and getting the Level III signature. Automating the wrong step delivers nothing.

Finally, validate before you deploy. Whatever route you choose, prove on a reference file that the numbers in your generated report match the numbers the analysis software displays, and keep that comparison as a controlled record. It costs a day, it satisfies auditors, and it is the difference between an efficiency gain and a systematic reporting error replicated across every job you issue.

Request a consultation