For some testing coming up, I wanted to be able to create display panels. Something like this:
Nothing exciting, just the ability to compare shots or parts of them and the individual and relative spectra. It should be easy with modern Field Processing Systems, but it is not the case. Most systems have some limited ability to produce panel displays, but it is tedious at best and there is also the problem of getting the message through to the processor. Although there are some good ones, in a lot of cases, they are more interested in sleeping, eating or tugging their slugs than doing useful work.
However, I digress.
To solve my problem, I dusted off some old code and created what I call SEGPanels:
It handles SEGD and SEGY (and is not available for download)
In the process I had another look at the SEGD and SEGY standards.
I wish I hadn’t.
But what makes a bad story worse is the latest incarnation of SEGD.
I knew version 3 had been released, but had not looked at it closely. It makes death look attractive.
The description is available here:
http://www.seg.org/resources/publications/misc/technical-standards
The authors had a chance to create the first really useful, useable format for recording high volume oilfield seismic data. Instead they opted to modify the current abortion.
To be fair they have made some positive changes, like dropping multiplexed data, but they should have discarded the current pig’s breakfast entirely and created a new format from scratch that suits what we do.
Actually it boggles the mind that they have managed to make a bad format even worse.
Here is an extract from the document:
All General Header blocks except General Header Blocks #1–3 are optional, and can appear in any order
Optional and can appear in any order!!! What fuckwit thought of that one?
– From a file point of view the version is not identified until General header 2 is decoded
– They kept the Header blocks 1 and 2, hardly changed
– They kept channel sets
– They included even more optional blocks of crap
I wonder how many of the standards committee members actually deal with real seismic data. Have they ever had to read seismic data? Do they have the slightest idea of QC?
Do they even know what a seismic crew does?
I’ll tell you –
It records data, lots of it. Not much else. That’s its reason for being.
It does not need a complicated file format.
A simple flat file header of fixed size, fully described and no optional fields or blocks followed by the data comprised of a well defined trace header and then data repeated until all traces are written.
There is probably a need for a Manufacturer header and a user header, but nothing else.
It is time that the industry (and especially the SEG) recognises that there are (at least) two levels involved, not one seamless process. For the members of the SEG, these are:
– Acquisition
– Processing
The needs are very different.
SEGD V3 seems to be an attempt by a bunch of technical illiterate and inexperienced junior geophantasists to merge acquisition and processing. And it failed miserably. We can perhaps forgive the earlier versions of SEGD as processing and storage technology was in its infancy, but the creators of version 3 should hang their heads in shame. Sadly some of them are respected members of the industry, which is a sad reflection on our industry.
Incidentally, SEGD is not the only foul file format the SEG has created (SEGY, SEG2 and a couple of others come to mind). In fact I have not seen one recent/modern attempt that I consider worthwhile, with perhaps the exception of SPS, but of course that was not a creation of the SEG, was it.
It’s time the SEG recognises that their role is to ratify formats, not create them.
In other words, they need to stay away from things they know absolutely nothing about.
