Some consumers of icon files such as py2exe care about the order that icon sizes are added, so the user should be fully in charge of this, instead of force sorting them.
No ci skip here because let's see CI run w/new version numbers. I'm starting to think (again) this bump should happen immediately after the release instead of right before the next? But I know @wiredfool had some objection to this at some point. As a compromise, maybe we could change to 2.9.0dev immediately following the release of 2.8.0.
HTTP response objects returned from `urllib2.urlopen(url)` or
`requests.get(url, stream=True).raw` are 'file-like' but do not
support `.seek()` operations. As a result PIL is unable to
open them as images, requiring a wrap in `cStringIO` or `BytesIO`.
This commit adds this functionality to `Image.open()` by way of
an `.seek(0)` check and catch on exception
`AttributeError` or `io.UnsupportedOperation`. If this is caught
we attempt to wrap the object using `io.BytesIO` (which will
only work on buffer-file-like objects).
This allows opening of files using both `urllib2` and `requests`, e.g.
Image.open(urllib2.urlopen(url))
Image.open(requests.get(url, stream=True).raw)
Does not change testing on other files, but fixes a case which previously made PIL collapse.
The Bitmap was a 1x1 RGBA and provoked an exception in PIL, but every Image viewer can load it.
Fixed code with comparison of header size, compression type and loading type of masks and fixed it.
Error happening in Python 3.x with P images:
in original code, palette data was created from a list of bytestrings. Changed to a full bytestring.
- `b"".join(list of bytestrings)` works in python 2.7 and 3.x
- `b"".join(bytestring)` works in python 2.7 but fails in python 3.x
No need to `join` anymore. Works in 3.x
Fixed loading of all types of provided images (+rgba). Added edge case where the header is reported as 40 bytes long with BITFIELDS (they start past the 40 bytes of the header). Loading fails for RLE, but IIRC, they're unsupported so it's normal.
