Reading SEG-Y from Command Line

Yes, I've been gone for a month or so...

Here it is. If you don't have your favorite reader use these fun dd & hexdump commands from the command line.

Reading the EBCDIC header:
dd if=input_file.sgy conv=ascii conv=unblock


Reading the job number
hexdump -C -s 3201x -n 3 input_file.sgy | awk '{print $2 $3 $4;}'

Reading the line number:
hexdump -C -s 3205x -n 3 10_770.sgy | awk '{print $2 $3 $4;}'

Reading the reel number:
hexdump -C -s 3209x -n 3 10_770.sgy | awk '{print $2 $3 $4;}'

Reading the format code:
hexdump -C -s 3224x -n 2 10_770.sgy | awk '{print $2 $3;}'

Reading the sample interval:
hexdump -C -s 3216x -n 3 10_770.sgy | awk '{print $2 $3;}'

Reading the samples per trace:
hexdump -C -s 3220x -n 2 10_770.sgy | awk '{print $2 $3;}'

Reading the sort code:
hexdump -C -s 3228x -n 2 10_770.sgy | awk '{print $2 $3;}'

Arc Seconds to Degrees

Wouldn't you know it. I thought that I was just dim-witted or the people who were writing the SEG-Y were completely zonked - but there is a reason behind putting X/Y data in arc seconds. For a long time, every once in a while you'll come across SEG-Y byte location 98 and it'll have a 2 there (meaning the coordinates are in Arc Seconds. I'm scratching my head saying - who on earth, why on earth? Okay, here's the rhyme - not sure of the reason.

Arc Seconds = 3599.99999712 * degree
while
Degree = 0.0002778 * arc seconds

go figure. I got this all from here.

Grazie

Nav2KML update

Yeah, I know script files are not that fun.  Here's the actual application that I put together the past few days.  I added the function of color to it.  It works the same way the script worked (the input) which should look like:

-122.19785 37.5686 101A
-122.19785 37.56863 101A
-122.19785 37.56865 101A

Added a few other things.  Hope you enjoy it.  Here's a screen shot and it's result.

Screen shot

What it should look like in GoogleEarth

SEG-Y Summary Update

Hey people,

I've been working on this program to add a little bit more functionality to it.  I added an EBCDIC/ASCII header viewer and a trace header viewer.  I might (if I have the time) add some functionality to it regarding being able to load large 3D files.  Get the app here.

SEG-Y Summary screen shot

SEG-Y Summary

Okay, here it goes.  My first professional swing at VB (the compiled version).  SEG-Y summary is a real application that reads in SEG-Y files, gives you info from the binary header and some (here's the some) -> It give you the first/last min/max info.  I couldn't find any other free application which gives you min/max info which I could find.   It's cheap & free and here.  Enjoy.  Careful of 3D files, it's a memory hog.  I might be working on a quicker way to load the files - but more of that later.

Here's how to use it:
Load the file you want look at
Select the header you want to summarize

Real tough.

Leave My Files Alone!

A big thumbs up for the SEG-Y Viewer brought to you by IHS.  I think you have to pay for it now.  It lets you view SEG-Y files without locking them up.  Unlike SeiSee, you get to see the full amplitudes.  For whatever reason, SeiSee only lets you look at 3 decimals to the right.  SEG-Y Viewer lets you look at the whole shebang.  And SegY Detective lets you as well - but it locks up the file.

Yes, I know that you need to keep the file open to look at it, but after everything's loaded into memory - let go of it.  Are people afraid of someone else in the network will change the file you're working on?  Nunno.

Locking files up can be disastrous for people trying to view seismic files in multiple application.  Yes, you might have worked long and hard on your software, but it doesn't do everything.

My two cents.

The SEG-Y Structure, Part 1

Okay.  I've been analysing 2D SEG-Y files all day today - on the binary level.  There may be a more in-depth analysis of it - but here's my shot.

SEG-Y Structure
We all know SEG-Y files are structured as
File Header
3200 byte EBCDIC/ASCII header
400 byte binary header
Trace Info
240 byte trace header
Sample Info
.....
wash, rinse, repeat with the trace header info - sample info

DWord/Word
After looking over the binary header & header info, I know we have the 2 byte integer type and the 4 byte integer types.  There seems to be more to it than that if you want to be able to translate things to the normal/rational world.

Here's my first example:

If you look at things on the binary level of this file you'll see:

Now, You have the -1000 number represented as FC18.  Remember it's a 16 bit WORD.  After you bring it into the real world it'll become a -1000.

Hex DWORD:  FFFFFC18 = -1000
Hex WORD:  FC10 = -1000

Look at byte location 73-76 and you're going to expect to find -293373438.  Okay, since it's a DWORD Int we're looking for:

Hex DWORD:  EE837A02 = and suddenly you get -293373438.  Whala!

If you worked for the SEG-Y subcommitee or commitee you probably already understand this.  I just figured it out in my lowly-mentality-self.