how to convert 3 byte to float

John Machin sjmachin at lexicon.net
Sun Dec 9 15:06:20 EST 2007


On Dec 10, 3:40 am, marek.ro... at wp.pl wrote:
> Mario M. Mueller napisa³(a):
>
> > Personally I would expect simple counts (since other seismic formats don't
> > even think of using floats because most digitizers deliver counts). But I
> > was told that there are floats inside.
>
> > But if I assume counts I get some reasonable numbers out of the file.
>
> I looked at the data and it seems to be 24-bit big-endian integers.

Agreed. The first byte is only 0x00 or 0xFF. Where the first byte is
0x00, the 2nd byte is only 0 or 1. Where the first byte is 0xFF, the
second byte is only 0xFE or 0xFF. The 3rd byte is more-or-less
uniformly distributed. In other words, I see no indications that the
data is other than 24-bit big-endian twos-complement integers. The
actual range of the sample needs only 10 bits.

*If* it is floating point, it's either unnormalised or a weird format
or both.

> I even plotted it and the graph looks quite reasonable (though I have no
> expertise in seismic data at all).

Same here.

>
> > But I'm experiencing some strange jumps in the data (seismic data is mostly
> > quite smooth at 40 Hz sampling rate). I think I did some mistake in the
> > byte order...
>
> Probably. In your code sample, when you pad it to 32-bits, why are you
> inserting every third byte, instead of the most significant one? Maybe
> the following will work:
>
> if sign:
>     s = struct.unpack('>i','%c%c%c%c' % (chr(0xFF),s0,s1,s2))[0]
> else:
>     s = struct.unpack('>i','%c%c%c%c' % (chr(0x00),s0,s1,s2))[0]
>

s/Probably/Definitely/
s/Maybe/Definitely/
:-)
Cheers,
John



More information about the Python-list mailing list