Skip to content

Imread format: unclear what are allowed values #19907

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nscozzaro opened this issue Apr 8, 2021 · 6 comments · Fixed by #19924
Closed

Imread format: unclear what are allowed values #19907

nscozzaro opened this issue Apr 8, 2021 · 6 comments · Fixed by #19924

Comments

@nscozzaro
Copy link

In this description, the documentation provides no instruction on allowed values. This information is necessary in order to properly use the function. For example for a jpeg do you add format='.JPEG', 'JPEG', 'jpeg', 'JPG' etc...

format : str, optional
The image file format assumed for reading the data. If not
given, the format is deduced from the filename. If nothing can
be deduced, PNG is tried.

@nscozzaro nscozzaro changed the title Imread allowed formats: unclear what are allowed value Imread format: unclear what are allowed values Apr 8, 2021
@jklymak
Copy link
Member

jklymak commented Apr 8, 2021

We could probably just point to PIL.Image.open here. If I understand the PIL docs this list of formats depends on your installed libraries, so I'm not sure we can or should explicitly list the allowed formats. Also, these things are pretty standard.

@tacaswell
Copy link
Member

We special case png to a known fast path (which is probably an artifact of us formerly owning a wrapping of lib png) and some special casing of urls, but otherwise we fall back to PIL.Image.open. That is probably worth noting (and directing people to please do that directly and not use imread!).

I have several concerns about documenting supported extension here. As @jklymak points out the list may depend on exactly how PIL is compiled or what other libraries are installed, we do not want to document any normalization / aliasing that PIL may do (as if they change that then our docs would be wrong!), and finally the extension on a filename is at best a hint of what is actually in the file (I can name a png blah_blah.jpeg). Almost all file formats have some "magic bytes" at the start to identify them (see https://en.wikipedia.org/wiki/List_of_file_signatures), I expect that PIL has some fallback paths where it reads the first couple of bytes and then dispatches based on that.


TLDR: 👍 on linking to PIL.Image.open 👎 on listing anything about file extensions.

@nscozzaro
Copy link
Author

nscozzaro commented Apr 8, 2021

please do that directly and not use imread

Are you saying you think imread should be removed from matplotlib? That actually would make more sense to me, if it's essentially just a wrapper for PIL.Image.open

@jklymak
Copy link
Member

jklymak commented Apr 8, 2021

Yes it is a vestige of when PIL was a difficult dependency/didn't exist. Also Matplotlib has a legacy in matlab, which has imread. I think there is general consensus that we should try to stick to just plotting and not emulate everything matlab does. OTOH deprecations are painful particularly for simple wrappers, so...

@nscozzaro
Copy link
Author

Just for context of how I ended up frustrated with the docs, I ran into this problem:

And solved it like this:

from PIL import Image
import requests
import matplotlib.pyplot as plt
url = small_df.at[0, 'image_url']
response = requests.get(url, stream=True)
img = Image.open(response.raw)
plt.imshow(img)
plt.show()

I didn't know at the time that Matplotlib was using PIL behind the scenes, but that was my solution anyways.

@tacaswell
Copy link
Member

Are you saying you think imread should be removed from matplotlib?

If we were starting from scratch I would be against putting it in, but it has been there from 2004 and removing it would break a lot of people for mostly aesthetic reasons...so it stays.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants