Simplify handling of remote JPGs

[rsignell-usgs]

Would it be possible to enhance Matplotlib to allow "im=imread(url)"
to work if url returns a JPG?

Currently (it seems):

• If the URL returns a PNG this works:

im = imread(urllib2.urlopen(url))

• If the URL returns a JPG, this DOESN'T work:

im = imread(urllib2.urlopen(url))

.. and neither does this:

im = imread(urllib2.urlopen(url),format='jpg')

... but this DOES work:

im = Image.open(cStringIO.StringIO(urllib.urlopen(url).read()))

See an example in Ipython Notebook here:
http://nbviewer.ipython.org/3918576/

So could just be hidden from the user so that "im = imread(url)" would
just work for JPG (assuming PIL was installed)?

[tacaswell]

This seems like a judgement call to me and I am not sure which side I come down on.

On one hand following the batteries included philosophy: yes. On the other hand, do one thing, mpl should be in the business of plotting, not munging data I/O: no.

I am not fully convinced mpl should have an imread (we only use it internally in tests and as part of an example in plot_directive).

[WeatherGod]

As an argument for imread(). I am often tasked with creating a plot that
includes certain static elements such as logos or specially designed
legends that my company would hire a designer to create. I would then use
imread() to read in that static element, and then use figimage() to display
it, unresampled.

With regards to the issue at hand, I really want to know why it is
necessary to use a StringIO object for JPEGs. Does the JPEG reader need
random access or something?

On Fri, Mar 20, 2015 at 10:51 AM, Thomas A Caswell <notifications@github.com

wrote:

This seems like a judgement call to me and I am not sure which side I come
down on.

On one hand following the batteries included philosophy: yes. On the other
hand, do one thing, mpl should be in the business of plotting, not munging
data I/O: no.

I am not fully convinced mpl should have an imread (we only use it
internally in tests and as part of an example in plot_directive).

—
Reply to this email directly or view it on GitHub
#4252 (comment)
.

[tacaswell]

But if is anything but a png we are delegating down to PIL anyway. I would argue in those cases you should use one of the (many) other libraries that focus on dealing with image I/O.

[WeatherGod]

perhaps, but I am usually dealing with PNGs, and imread() "just works" for
that. In any case, matplotlib has the imread() function. And it is failing
to read JPEGs in certain situations. The question still stands: why?

On Fri, Mar 20, 2015 at 11:14 AM, Thomas A Caswell <notifications@github.com

wrote:

But if is anything but a png we are delegating down to PIL anyway. I would
argue in those cases you should use one of the (many) other libraries that
focus on dealing with image I/O.

—
Reply to this email directly or view it on GitHub
#4252 (comment)
.

[mfitzp]

Just had a look at this. Like @tacaswell mentions the reason for the slightly confusing behaviour is that matplotlib includes a specific library to handle .png files (_png.so) to which those requests are handed off. Everything else however goes through PIL (or PIllow) which is where the .jpg load is failing. The _png.so library handles url handles fine while PIL does not.

There is a StackOverflow post here that describes the StringIO (later io) methods as being required for PIL to open files from URLs. Perhaps Pillow is a better place to fix this?

I've put together the fix and opened a bug against Pillow for discussing it there.

[mfitzp]

@rsignell-usgs @WeatherGod I've submitted a PR to Pillow to add support for opening via file-like handlers (such as HTTP response objects). Hopefully it will make it into Pillow 2.8.0.

[tacaswell]

I am going to close this on our side as @mfitzp has fixed this upstream ;)