SeisKit.jl supports all revisions of the SEG-Y standard, but is mostly tested with post-stack seismic data. Compared to previous attempts (listed in the README), this package provides convenience functions to access SEG-Y headers and is more idiomatic for Julia users:
We plan to add more convenience functions very soon to extract coordinate reference systems (when available) and to post-process the resulting traces into seismic images and cubes.
If you work with seismic data, please give the package a try. We want to make sure it works for all corner cases, with pre- and post-stack datasets. Contributions are very welcome.
Hi Julio, this looks like a valuable addition to the Julia ecosystem. Much appreciated.
Automatic loading of SEGY files worked well and fast in a couple of datasets I tried. The convenience tools to access the headers in Julia are also excellent.
Here is some high-level feedback, FWIW.
In many real-world scenarios, manual input may be needed to define and/or override any missing or incorrect data in the input file. This could include defining 2D vs. 3D data, time vs. depth domains, CRS (when implemented), sample format (IBM or IEEE), the number of samples per trace, the time/depth of the first sample, the sample period or the coordinate scalers. The code should also enable us to define byte headers for X–Y coordinates, CDP and shotpoint numbers (for 2D), and for inline and crossline numbers (for 3D).
The fact that SeisKit,jl does not support saving older SEGY format revisions seems to be a limitation, given the industry’s reluctance to abandon SEGY rev1 and the many legacy codes that only read this older version.
Good to hear! We could be 2x faster, but the Julia compiler has a limitation with large union types and we had to do this hack with WrappedUnions.jl:
If you remove all the number types and only support the floating point variants, you can get an additional 2x speed.
Unfortunately the SEG-Y specification doesn’t provide a field for 2D vs. 3D seismic. If you know this information, I believe the only thing you can do is add to the textual headers. You can do that by modifying the Segy.textualheader(fname).content as explained in the README.
You can modify the binary header, the struct is mutable.
This one is rarely saved in a single place. There is a stanza in SEG-Y rev 2 that introduced CRS, but no one uses it in practice. You could modify the Segy.extendedheaders to include that or the Segy.textualheader.
These ones are automatically detected and fixed based on the fields of the binary and trace headers. The code is very clean, you can take a look to see what is done exactly.
In general, you can modify all these fields manually, and reconstruct the Segy.Dataset with the modified headers. We provide a Segy.fixissues that does a couple of fixes.
Agree. I believe that we could relax this design choice in the future. On the other hand, the SEG committee strongly advises to save in the latest revision. This “limitation” is a way to enforce it on users who don’t know what to do to update to rev 2.1 (probably due to lack of software).
Please feel free to add more suggestions. They are super welcome!
@rafael.guerra I’ve just released a new version of the package with new utility functions:
Segy.crs
Segy.coords
Segy.image
Appreciate it if you could test with the seismic data you have to make sure we have robust heuristics to extract metadata (when available).
Also, free feel free to add tests with public datasets. We need to increase test coverage, and it should be straightforward to add more tests based on the existing ones.
I will try to update the documentation in the README when I find some time.