Closed mochetts closed 1 year ago
Some more context... looking at the byte array of the first sample != 0 from the first trace this is what I see:
01000010 00110001 01110110 11110001
0x42 0x31 0x76 0xF1
This represents exactly 44.366153717041016
in Float32 which is what my javascript parser is reading...
Still puzzled why segyio reads 49.46461486816406
Hi @mochetts
You appear to be laboring under the assumption that SEG-Y files exclusively use IEEE-754 floating point representation. This has only actually been possible since SEG-Y rev.1
Unfortunately when you interrogate this particular file...
f = segyio.open('segyio-notebooks\\data\\basic\\3X_75_PR.SGY', strict=False)
print(f)
... you'll find that what you have is: float representation: 4-byte IBM float
which is necessarily the case because:
f2.bin[segyio.binfield.BinField.SEGYRevision]
returns 0
I suggest reading more about IBM floating point, and there's a nice online calculator which should help you figure out how to deal with this in Javascript.
Thanks for the response @da-wad. Much appreciate it.
Hi! I'm building a segy reader in javascript and I'm comparing the results of my reader with your reader here.
So far so good except that I get some differences when reading the trace samples on the first trace of this file.
Considering only the first trace (CDP 1) of that file...
This is what I get when reading a 4 bytes float number using big endian for the first 5 samples different from 0 (from sample index 188 on):
And this is what segyio is reading for the same 5 samples:
It seems that some values are exactly doubled by segyio and some others have a different transformation that I can't seem to figure out...
So was wondering... is this a bug on my code? a bug on segyio? Is it that segyio applies some sort of transformation to the numbers?
I'm looking at this code trying to figure out if this is the right place where segyio reads data but it's getting super hard to follow for me. Am I in the right place here?
Thanks!