Fixed point with gain data format

[jcapriot]

I've been writing a data reader in Cython for my own purposes and was trying to look for any examples of actually correctly reading in the fixed point with gain data type format (format 4). Looking through your code base it seems that it is incorrectly interpreted as a 4 byte IEEE float number, (you should probably switch this to an unsupported error within segyio if it encounters this data format...). To that end, do you have any example files that were written using this format?

For reference, according to the SEG specs, the 4 byte fixed point is essentially two 2byte pairs of numbers,

bytes 1 and 2	byte 3 and 4
Gain	value

Where essentially value is an int16_t and gain could be interpreted as an uint16_t that is limited to UINT8MAX (it only uses 1 byte of the 2 byte uint16_t).

Even the SEG revision documents cannot agree on how to interpret this... from revisions 0 and 1 this is to be interpreted as $value * 2^{gain}$, but on revisions 2 and 2.1, it is said to be interpreted as $value * 2^{-gain}$. I suspect that the original revisions were correct and that revisions 2 and 2.1 were incorrect, but again I can't verify this without a known file being read correctly in the first place.

I do realize that this format is probably extremely unlikely to ever be encountered, but I was going for a completeness-sake on my own end.

[achaikou]

Hi!

Thanks for making a note in the issues. It would be a good place to explain current behavior. 😃

We refer to "fixed point with gain values" format sometimes when going through all formats in the list, but behavior itself is not implemented as we too are yet to see files in format 4. Our main interface is python and from python you can't open such a file.
UserWarning: Unknown trace value format 4, falling back to ibm float

We do not have any files written in format 4. Files at test-data/multiformats/Format4?sb.sgy actually are format 5 files, not format 4. I believe they were included as a placeholder, but were never used in tests.

We too have noticed that definitions of some formats are slightly changed between revisions. I have no clue which definition is correct in this case.

Due to vague specification/format being obsolete/no existing files in that format we do not plan to do anything further so support it.