-
Notifications
You must be signed in to change notification settings - Fork 215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trouble Reading SEG-Y Rev 2 #419
Comments
Hi, Nick, and thanks for a great report! Actually, support for large traces as in SEG-Y v2 was merged just a few days ago [1], but it's not been made part of a release yet. I think this issue is sufficient motivation for me to push the next release forwards, so that you get to work with your file, at least if it uses the now unsignedness of the 16-bit samples word (115-116).
Of course, leave it to SEG to make an even bigger mess of this file format. I'm afraid there's no great push to support this kind of feature as of yet, as the logic that determines file size relies on samples-per-trace being constant, and in this header word. It shouldn't be too difficult to fallback to reading 137-140 under certain conditions, but to make it intuitive and robust is still quite time consuming, so I cannot make any promises. It's more likely that support for this kind of behaviour would come with a segyio 2.x series than it being incoporated in the 1.x series. For what it's worth, it seems like you're using segyio correctly, it's just that support for long traces from rev2 hasn't been implemented properly (other than when 115-116 is interpreted as unsigned. [1] fd5f9ab |
Thanks for your response! I work for a nonprofit called IRIS, where we maintain a repository of active source experiments that researchers request via web services in SEG-Y format. The web service supports SEG-Y revision 2 as an output format, but unfortunately information is lacking about best practices/conventions for this format. For instance, what do you put in the standard trace header (bytes 115-116) when too large a number of samples is requested and the extended trace header needs to be used? Nonetheless, the segio library has been very useful for me to debug problems with our extraction program. I'm really looking forward to the enhanced support of SEG-Y rev 2 features in segio. Thanks for all you do. |
Has support for extended number of sample traces been included in the 1.9.0 version of segyio? This is what it states in the release notes. segyio has learned to work with with >32k samples per trace The reason I am asking is that I am running version 1.9.0 but it still comes up with
|
I'm having trouble reading SEG-Y revision 2 data using the segyio library.
For SEGY Rev 1, there is a limit of 2^(16-1)-1=32767 samples per trace (the maximum 16bit signed binary integer). This number is set in the 240-byte standard trace header bytes 115-116.
SEGY Rev 2 among other things is supposed to increase the maximum number of samples per trace to 2^(32-1)-1 = 2147483647. Since any number of samples greater than 32767 is too large to fit in the 2 bytes (115-116) of the standard trace header, one needs to put a value in the extend trace header bytes 137-140. As the SEG-Y Rev 2 spec indicates, this extended header should appear immediately after the SEG-Y standard trace header.
I believe the convention is that if the number of samples per trace is greater than 32767, then one should enter 32767 in the standard trace header (bytes 115-116), and also enter the large value in the extended trace header (bytes 137-140).
Nonetheless, when I try to read a file that does this using the
segyio
library I get the following error:I think this is because the library isn't reading the trace length value that was entered in the SEG-Y rev 2 extended trace header.
Does anyone know why this isn't working? Is the convention I'm using for entering the number of samples per trace in the extended trace header correct?
Thanks for any help you can provide!
The text was updated successfully, but these errors were encountered: