From SubSurfWiki
(Redirected from SEG Y)
Jump to navigation Jump to search

SEG-Y (with a hyphen, which is how it appears in the standard documentation), also known as SEGY and SEG Y, pronounced 'segg why', is a seismic data file format. The name stands for the Society of Exploration Geophysicists 'Y' format. The format was intended for data exchange — and was related to the defunct SEG-X (for 'exchange) format — but it has become the de facto standard for processed reflection seismic records. Other standards, such as SEG-D for field records, deal with other data types.


SEG-Y means seismic data. For many of us, it's the only type of seismic file we have much to do with — we might handle others, but for the most part they are closed, proprietary formats that 'just work' in the application they belong to (Landmark's brick files, say, or OpendTect's CBVS files). Processors care about other kinds of data — the SEG has defined formats for field data (SEG-D) and positional data (SEG-P), for example. But SEG-Y is the seismic file for everyone. Kind of.

The first rule of the SEG-Y format is that no-one follows the SEG-Y format.

The open SEG-Y "standard" (those air quotes are an important feature of the standard 😄 ) was defined by SEG in 1975. The first revision, Rev 1, was published in 2002. The second revision, Rev 2, was announced by the SEG Technical Standards Committee at the SEG Annual Meeting in 2013 and I imagine we'll start to see people using it in 2014.

Revision 0

The original SEG-Y data exchange format was introduced in 1975.[1]

Revision 1

New high-density media and the widespread adoption of 3D seismic data necessitated an update to the format. Rev 1 was adopted in 2002 and introduced the following improvements over the original specification:[2]

  • File may be written to any medium that is resolvable to a stream of variable length records.
  • Data word formats now include 4-byte IEEE float and 1-byte integer words.
  • A small number of additional fields in the 400-byte binary file header and the 240-byte trace header were defined.
  • Some other fields in those headers were clarified.
  • An extended text file header, consisting of additional 3200-byte blocks, was introduced.
  • The data in the extended header uses a stanza layout; standard stanzas were defined.
  • Trace identification was expanded.
  • Engineering conversions were introduced.
  • The text file header can be ASCII encoded, not only EBCDIC.

The byte stream of a Rev 1 file looks like so:

SEGY file byte stream structure.svg

This table only shows the most important items. Rows labelled strongly recommended are noted as such in the SEG-Y standard specification.[2] Those fields marked recommended are worth using as defined here, based on experience.[3]

Start byte Bytes Description Note
1 4 Trace sequence number within line Strongly recommended
9 4 Original field record number Strongly recommended
13 4 Trace number in original field record Strongly recommended
29 2 Trace identification code, see below Strongly recommended
115 2 Samples in trace Strongly recommended
117 2 Sample interval, ms Strongly recommended
181 4 X coordinate of ensemble position of this trace Recommended
185 4 Y coordinate of ensemble position of this trace Recommended
189 4 3D inline number Recommended for 3D
193 4 3D crossline number, usually same as ensemble number in bytes 21–24 Recommended for 3D
197 4 Shotpoint number, probably 2D only Recommended for 2D

See the full table

Revision 2

The byte stream looks like:

SEGY rev 2 stream.png

Rev 2 was approved in March 2017; It has the following features:[4]

  • Allow up to 65 535 additional 240-byte trace headers; bytes 233–240 reserved for trace header name.
  • Stanzas can appear after the trace data in a 'data trailer'.
  • Support up to 232 – 1 (that's nearly 4.3 billion!) samples per trace.
  • Support up to 264 – 1 (1.8 × 1019) traces per line or ensemble.
  • Permit arbitrarily large and small sample intervals.
  • Support 3-byte and IEEE 8-byte (64-bit) sample formats.
  • Support little endian and pairwise byte swapping.
  • Support microsecond date and time stamps.
  • Provide for additional precision in coordinates, depths, elevations.
  • Synchronize coordinate reference system specification with SEG-D Rev 3.
  • Include depth, velocity, EM, gravity and rotational sensor data.
  • Backward compatible with Rev 1, as long as undefined fields were filled with binary zeros.

SEG-Y file handling libraries

Most proprietary seismic interpretation software has a way to read SEG-Y data into the application. The only open source application we know of is OpendTect.

There are several Python libraries for reading SEG-Y files, for example:

  • segyio, by Jørgen Kvalsvik and others at Equinor.
  • SegPY, by Rob Smallshire and others.
  • ObsPy, by Moritz Beyreuther and others.

If you just want the SEG-Y data in some other format, e.g. an image, then I have used segy2ascii with good results.

See also

  • SEG-D for field data
  • SEG-P for positional information
  • SEG-2, another format, most recently seen in the wild as a GPR format


  1. Barry, K, D Cavers, and C Kneal (1975). Report on recommended standards for digital tape formats. Geophysics 40 (2), 344–352. Online PDF.
  2. 2.0 2.1
  3. Assertion by Matt 13:59, 3 January 2013 (UTC)
  4. SEG-Y Rev 2 specification, SEG Technical Standards Committee. PDF:

External links