There are two file formats that dominate well log data storage and exchange, and they couldn't be more different. LAS files are plain text, human-readable, and easy to parse. DLIS files are binary, richly structured, and notoriously difficult to work with. Both store the same fundamental thing — measurements taken as a function of depth in a wellbore — but they make radically different trade-offs in how they do it.
If you've spent any time in petrophysics, you've probably developed a strong preference for one over the other (it's almost certainly LAS). But understanding when each format is the right choice — and how to move data between them without losing information — is essential for anyone managing well log data at scale.
A Brief History of Well Log Formats
The timeline matters because it explains why both formats still coexist.
LIS (1974/1979): The Log Information Standard was developed by Schlumberger and became the first widely adopted binary format for digital well log data. LIS was designed for magnetic tape — a physical medium with fixed storage constraints — and its file structure reflects that lineage. A large number of archived files from the 1970s through the early 1990s still exist in LIS format. They require specialized software to read, and working with them is an exercise in digital archaeology.
LAS (1989): The Canadian Well Logging Society introduced the Log ASCII Standard specifically to address the accessibility problem. LIS and other binary formats required proprietary software from the logging vendor; LAS files could be opened in any text editor. The format was simple by design — a header with metadata, followed by a whitespace-delimited data table — and its adoption was immediate and global. LAS 2.0 followed in 1992 to clean up some ambiguities, and remains the dominant version today.
DLIS (1991): The Digital Log Interchange Standard (formally API Recommended Practice 66, or RP66) was published by the American Petroleum Institute as the successor to LIS. It preserved the binary, richly-structured approach but modernized it with an object-oriented data model, support for multi-dimensional data, and a standardized metadata schema. Stewardship transferred to POSC (now Energistics) in 1998.
So the industry adopted a simple ASCII format and a complex binary format within two years of each other, and has been living with both ever since. This isn't a mistake — it reflects a genuine split in requirements.
LAS: What It Is and What It Isn't
A LAS file is a flat ASCII text file containing one well's log data in a single table. Every column is a curve. Every row is a depth (or time) step. The header sections describe the well, the curves, and the logging parameters. That's the entire data model.
What LAS does well:
Human-readability is the killer feature. Open a LAS file in Notepad, Vi, or cat and you can see exactly what's in it — the well name, the curve names, the units, the data values. This transparency makes debugging trivial. When your petrophysics software throws an error on import, you can open the file and often spot the problem in seconds.
Parsing simplicity follows from readability. Writing a LAS parser from scratch takes an afternoon in any programming language. The lasio Python library handles even malformed files gracefully, and it's not because the library is especially clever — it's because the format is straightforward enough that edge cases are manageable.
Compression efficiency is an underrated LAS advantage. Because LAS files are ASCII text, they compress extremely well. A 50 MB LAS file might compress to 3-5 MB with gzip or zip. This matters for data transfer, archival, and cloud storage costs.
Universal tool support is the practical result. Every petrophysics software package on the market reads LAS. Most geological modeling, reservoir simulation, and data management tools do too. There is no compatibility question.
What LAS cannot do:
One well per file is a hard constraint. You cannot store multi-well data in a single LAS file.
One data table per file means all curves must share the same index (depth or time) and sample rate. If you have wireline curves sampled at 0.5 feet and image log data sampled at 0.1 inches, they cannot coexist in the same LAS 2.0 file. (LAS 3.0 addresses this with multiple data sections, but adoption has been negligible.)
No array data support is the deepest limitation. A LAS curve is a single value per depth. Acoustic waveform data, borehole image data, and spectral measurements are multi-dimensional — at each depth point, they contain an array of values across time, angle, or frequency. LAS can technically store this by flattening each element into its own column (e.g., WF001, WF002, ... WF512 for a 512-sample waveform), but the result is unwieldy — hundreds of columns, no structural indication that they form an array, and massively inflated file sizes.
No metadata richness beyond the basics. LAS captures well identification, logging parameters, and curve descriptions. It does not capture calibration records, tool provenance, processing history, or the detailed environmental parameters that went into log corrections.
DLIS: Power at the Cost of Complexity
A DLIS file is a binary container that holds one or more "logical files," each containing an object-oriented data model of sets, frames, and channels. Where LAS is a spreadsheet, DLIS is a database.
The data model:
The content of a DLIS file divides into two primary components: sets and frames.
Sets are metadata tables. Each set contains objects that describe some aspect of the logging context — the tools used, the parameters configured, the calibration coefficients applied, the processing steps performed. Sets follow the RP66 schema and can be extended with vendor-specific object types. This extensibility is both a feature and a source of interoperability headaches.
Frames hold the actual measurement data. A frame is a collection of channels that share the same index (depth or time axis) and sample rate. Each channel can be one-dimensional (a single scalar per depth — like a standard log curve), two-dimensional (an array per depth — like an azimuthal image), or even higher-dimensional. Multiple frames can coexist in a single file, each at a different resolution. Common resolutions include 6-inch, 3-inch, 2-inch, 1.5-inch, and 1-inch sample intervals.
This is the fundamental advantage over LAS: a single DLIS file can contain your standard wireline suite at 6-inch sampling alongside your FMI image data at 0.1-inch sampling alongside your acoustic waveforms at 1-inch sampling — each in its own frame, each with proper array dimensionality, all accompanied by complete metadata about how the data was acquired and processed.
What DLIS does well:
Multi-dimensional data storage is the primary justification for DLIS's existence. Borehole images, acoustic waveforms, NMR T2 distributions, and spectral data are inherently array-valued, and DLIS represents them natively. Any workflow involving these data types effectively requires DLIS (or a modern alternative like HDF5).
Complete provenance tracking through calibration objects, tool objects, and process objects means you can trace any computed curve back through its processing chain to the raw measurement. This is invaluable for quality control and regulatory compliance.
Multi-run storage lets a single file contain data from multiple logging passes at different depth intervals, without ambiguity about which measurement came from which run. The Origin concept tags each channel with its source, so data from different runs can be merged but remain distinguishable.
What makes DLIS difficult:
You cannot open a DLIS file in a text editor. This sounds trivial, but it fundamentally changes the debugging workflow. When a LAS import fails, you look at the file. When a DLIS import fails, you need specialized software or a Python script just to understand what's in it.
The format was designed for writing, not reading. The dlisio documentation puts it bluntly: "The files are structured in such a way that data can be written directly while acquiring the logs. This is very handy for the producers of the files, and equally tedious for the consumer that wants to read them later on." The format was optimized for the logging truck, not for the office.
Vendor-specific dialects are a constant problem. DLIS is a permissive standard — it defines general data structures but allows producers to modify them and add completely new structures not defined in the spec. The result is that different service companies produce DLIS files with vendor-specific flavors that aren't fully compatible with each other. Schlumberger's DLIS-to-ASCII converter explicitly notes it may not fully read DLIS files produced by other vendors. Some DLIS viewers crash on files that are technically spec-compliant but use structures the viewer doesn't expect.
Software support is limited compared to LAS. While the major petrophysics packages (Techlog, IP, Geolog) handle DLIS well, many smaller tools, open-source projects, and custom scripts cannot. The dlisio Python library (developed by Equinor) has dramatically improved programmatic access, but it's still a complex API reflecting a complex format.
File size can be enormous. Because DLIS files can contain array data from multiple tools and runs, individual files can reach hundreds of megabytes or even gigabytes. The binary encoding is more storage-efficient than ASCII for the same data, but the total data volume in a DLIS file is typically much larger because it contains data that would be spread across many LAS files (or wouldn't be stored in LAS at all).
The Decision Framework
The choice between LAS and DLIS isn't really a format preference — it's determined by the data you need to work with.
Use LAS when:
You're working with standard scalar curves — gamma ray, resistivity, density, neutron, sonic, caliper, SP. These are single-value-per-depth measurements that fit naturally into LAS's flat table structure. For the vast majority of routine petrophysical interpretation, LAS is sufficient and simpler.
You need maximum portability. If data needs to flow through diverse software tools, be reviewed by non-specialists, or be loaded into general-purpose databases, LAS is the path of least friction.
You're distributing or archiving data. LAS files compress beautifully, parse universally, and will still be readable in 50 years. The same cannot be said with equal confidence about DLIS, given its dependency on specialized parsing logic.
Use DLIS when:
You have array or image data. Borehole images (FMI, FMS, EMI), acoustic waveforms, NMR T2 distributions, and dielectric dispersion data are multi-dimensional by nature. Flattening them into LAS columns loses the dimensional structure and creates absurdly wide files. DLIS preserves the native array representation.
You need to keep multiple logging runs together. If regulatory or organizational requirements mandate that all data from a well be delivered as a single file with complete provenance, DLIS is designed for exactly this.
You need full metadata fidelity. Calibration records, tool configurations, environmental correction parameters, processing histories — if any of this metadata is critical to your workflow, DLIS preserves it where LAS cannot.
The practical reality: Most petrophysicists work with both formats routinely. Service companies deliver DLIS. Interpretation work happens in LAS (or internal database formats). The conversion step between them is where information is gained or lost.
Converting DLIS to LAS
Converting from DLIS to LAS is the most common format conversion in petrophysics, and it's inherently lossy. You're moving from a rich, structured binary format to a flat ASCII table. Some information loss is unavoidable — the question is what you lose and whether it matters.
What converts cleanly: Scalar curves (one value per depth) transfer directly. The depth index, curve mnemonics, units, and basic well identification all have natural counterparts in the LAS header.
What gets flattened: Array data must be split into individual columns. A 128-sample acoustic waveform at each depth becomes 128 LAS columns. A 192-sector borehole image becomes 192 columns. The data is preserved, but the structural relationship between elements is lost. Downstream software must be told (out-of-band) that columns WF001 through WF128 form a waveform array.
What gets lost: Calibration objects, tool provenance, processing history, and environmental parameters have no LAS equivalent. They either go into the ~P (Parameter) section as best-effort key-value pairs, into the ~O (Other) section as freeform text, or they're simply dropped.
What goes wrong: The most insidious conversion error is frame selection. A DLIS file may contain multiple frames at different resolutions. If the conversion tool doesn't let you choose which frame to extract (or worse, silently picks one), you may end up with the wrong resolution of data, or with a subset of curves that happened to be in the default frame.
Tools for conversion:
Schlumberger's Log Data Toolbox includes a DLIS-to-ASCII converter that can output LAS and delimited text formats. It works reliably on Schlumberger-produced DLIS files but may struggle with files from other vendors.
The dlisio + lasio Python combination gives you full programmatic control. Use dlisio to open the DLIS, select the frame and channels you need, extract them as NumPy arrays, and write them out with lasio. This is more effort than a GUI converter but gives you complete control over what gets extracted and how it's mapped.
Commercial petrophysics packages (Techlog, Interactive Petrophysics, Geolog) can export any loaded data to LAS, regardless of its original source format. If you already have the data loaded, this is often the simplest path.
Converting LAS to DLIS
Going the other direction — LAS to DLIS — is less common but comes up when organizations require DLIS delivery or when LAS data needs to be combined with array data in a DLIS container.
This conversion is structurally simpler (you're going from less structure to more), but the DLIS output will be sparse — it will have frames and channels but none of the rich metadata (calibration objects, tool references, processing history) that DLIS is designed to carry. The dliswriter Python package can create DLIS files programmatically, and Schlumberger's Log Data Toolbox supports LAS-to-DLIS conversion.
The Emerging Alternatives
It's worth noting that LAS and DLIS aren't the only game in town anymore. Several newer formats are gaining traction:
JSON Well Log format stores well log data in JSON structures that are both human-readable and programmatically accessible. Petroware has converted the entire Equinor Volve dataset to JSON format. The approach combines LAS's readability with better structural flexibility, though it hasn't achieved widespread adoption.
HDF5 is used increasingly in research and data science contexts for storing large multi-dimensional well log datasets. It handles array data natively, compresses well, and has excellent Python support through h5py. However, it lacks the domain-specific metadata schema that DLIS provides.
OSDU (the Open Subsurface Data Universe) is not a file format but a data platform standard that aims to unify subsurface data access through APIs. As OSDU adoption grows, the file format question may become less important — data would be accessed through standardized APIs regardless of how it's stored on the backend.
None of these have displaced LAS or DLIS yet, and realistically, both formats will remain in active use for years to come. The practical investment is in building a data pipeline that handles both cleanly.
PetroCurve cleans, views, and standardizes LAS curve mnemonics in your browser — drop a file, review the suggested mappings against industry naming conventions, and export a clean LAS 2.0 file. Your data never leaves your device. Try it free →