On Thu, 17 Dec 2015 04:37:26 +1100, Chris Angelico <ros...@gmail.com> wrote:
> On Thu, Dec 17, 2015 at 4:30 AM, Peter Pearson
><pkpearson@nowhere.invalid> wrote:
>> Agreed. It's annoying when an agency goes to the trouble of making
>> huge datasets available online, but fails to identify the format.
>>
>> But the 16-bits-per-pixel hypothesis is unlikely, given that each
>> byte tends to echo its predecessor:
>>
>> 0000130 ffff ffff ffff ffff ffff ffff ffff ffff
>> 0000140 ffff ffff ffff c0ff c1c0 c3c3 c3c3 c4c4
>> 0000150 c4c4 c3c4 c3c3 c4c4 c3c3 c3c3 c3c3 c3c3
>> 0000160 c4c4 c4c4 c5c4 c6c5 c7c7 c7c7 c5c5 c6c5
>
> Hmm. With just a few exceptions. Maybe it's two channels or something
> - is that what you mean by "taken at different wavelengths"?
Yes; but as described below, I now think they're taken at different times.
> Definitely it's begging for format identification from the source.
Agreed, again. But it's hard to set this kind of problem aside.
I split it into two images, thusly:
>>> half = len(rawdata)/2
>>> Image.fromstring("L", (9896, 3298), rawdata[0:half]).save("temp3.png")
>>> Image.fromstring("L", (9896, 3298), rawdata[half:]).save("temp4.png")
Flipping between the resulting two images, one sees slight displacements
of the large-scale swirly structures, so I'm pretty sure the two images
correspond to slightly different times. (I use the current GOES West
northern-hemisphere image as my desktop, so I'm pretty familiar with the
movements of atmospheric swirly thingies.)
This feels solved-enough to set aside now.
--
To email me, substitute nowhere->runbox, invalid->com.
--
https://mail.python.org/mailman/listinfo/python-list
