Why am I not able to read some images and why do some images get stretched or blurred on reading using 'imread' function?

When I am trying to read images using the 'imread' function, some files can be read and others cannot. I am not sure why that happens.

Also, some images get stretched on reading and others do not. I also see some blurring occur sometimes on reading the images.

How do I resolve these two issues?

Answer 1

[MathWorks Support Team]

Reading Files With 'imread'

The 'imread' function in MATLAB supports a variety of different image file formats as inputs, including but not limited to: '.bmp', '.jpeg', '.png', and '.tiff'. If an image file is not able to be read, please double-check that it is in a file format supported by 'imread', as well as the file is not corrupted or otherwise invalid. For a full list of supported file types, please see the 'imread' documentation:

https://www.mathworks.com/help/matlab/ref/imread.html

Images Appearing Blurry or Stretched

An image may appear stretched or blurry when displayed for a variety of reasons.

• Double-check the resolution and quality of the image file itself, as it may simply be low quality or low resolution on its own.
• If you are using 'imshow' to display an image, please double-check that the 'InitialMagnification' field is set to a value you are expecting. Additionally, saving an image in '.jpeg' format may contribute to some form of Lossy Compression, which will permanently delete image data for the sake of reducing file size. For more information about 'imshow', please see the following documentation page:

https://www.mathworks.com/help/images/ref/imshow.html?searchHighlight=imshow&s_tid=srchtitle_imshow_1

• If you are using 'imtool' to display the image file, check if MATLAB is currently in software OpenGL mode. This can be checked by typing the following command into the Command Window: 

  >> opengl info

  If this outputs something along the lines of:

                            Version: '1.1.0'
                             Vendor: 'Microsoft Corporation'
                           Renderer: 'GDI Generic'
                     MaxTextureSize: 1024
                             Visual: 'Visual 0x140, (RGB 24 bits (8 8 8), Z depth ...'
                           Software: 'true'
          SupportsGraphicsSmoothing: 0
      SupportsDepthPeelTransparency: 0
         SupportsAlignVertexCenters: 0
                         Extensions: {3x1 cell}
                 MaxFrameBufferSize: 0

  then images with a dimension larger than the specified "MaxTextureSize" parameter will appear blurry. To temporarily test if this is the cause, try the following command: 

>> opengl hardware

and try displaying the image again to see if the display quality improves.

The above is not an exhaustive list, and if you encounter an issue with a displayed image in MATLAB appearing stretched or blurry, and your case is not one of the above scenarios, please contact MATLAB Support.

​​​​​​

[Walter Roberson]

Saving images as JPG is often the wrong thing to do. Typical JPG blurs edges, making it difficult to do proper analysis of images.

You are typically better off using PNG.

The exception to this is that imread() deployed through Coder can only handle JPG if I recall correctly.

[DGM]

It's not clear to me why this was chosen to be a reference question, because on the face it does not appear to have a clear answer, and the given answer doesn't appear to answer it clearly.

"Some files can be read and others cannot" can be caused by any number of things far more likely than the image being something other than a JPG. The cause might be an invalid path, a corrupted file, or an incompatible format. It might not even be a failure to read, but a simple misuse causing unexpected results. It could be a mishandled indexed image, an image with mishandled alpha content, or a mishandled multiframe image. It might not even be a problem with imread(), but a misuse of imshow() that causes the confusion.

Unless it's a limitation that occurs in a specific context as Walter mentioned, why would JPG be required for reading? If it is such a context-specific restriction, why is that not mentioned in what is ostensibly a reference answer?

Why might an image be read as "stretched"? TIFF supports nonsquare pixel aspect ratio, so maybe that's one possibility. Why would the image be read as blurred? I could guess, but I don't have a good answer. I searched the forum for cases where either question was asked and couldn't find any examples. Do people frequently have problems with blurred results from imread()?

Why would stretching or blurring be fixed by setting the orientation metadata? As far as I know, imread() ignores that, and it wouldn't result in stretching or blurring either way. If the answer refers to something other than orientation metadata, then maybe that should be clarified.

[Walter Roberson]

If you image() an image and the image is smaller than the InnerPosition of the current axes, then the image could get magnified which would cause blurring. But using JPEG would only make that worse.

imshow() in typical use would resize the axes and figure to make it small in such a situation, avoiding the blurring that way.

imshow() does not resize if "hold on" or if the axes is not in the "default" position for a single axes in the figure, which is the hypothesis that you might have used subplot(). But again that is independent of JPEG.

My suspicion is that "save as JPEG" is short-hand for two possibilities:

• that the image might be an indexed (pseudocolor) image that is going to get the wrong color if not handled specially; or
• that the image might not be compliant with the standards for the kind of image it is supposed to be; if you can manage to open it in an image viewer or image editor and re-save it then probably the result will be more compliant

[DGM]

If that's the reasoning, then I'd say that the answer is inadequate in that

1. it doesn't explain or even disclose the presumed cause
2. the remedy is a poor solution in the specific case
3. and the remedy is bad advice in the general case

My primary beef is that these are supposed to be reference questions/answers. This isn't the first one that I've found that appears like it was content assembled by a scraping bot.

If posing a question to preface an instructive answer, then one has control over both. The question could have been made an answerable exemplar. The answer could have done something with it.

Re: image display vs axes aspect

Since the default display interpolation is nearest-neighbor, I'd consider that a possible explanation for the "stretched" problem description, but not "blurred". Maybe that's just my interpretation of the perceived effect, but I figure subjectivity is fair, given that this is all just guesswork for amusement. Either way, it's not a problem with imread().

[Stephen23]

"...these are supposed to be reference questions/answers"

Huh. Quite a number of them are half-baked, with questionable code practices. My favorite one is this one, which not only contradicted the documentation for many years, but then made an argument that:

• is logically unprovable by simple testing at the interface,
• can be trivially disproved.

So... hardly convincing of the mightly power of TMW "Support Team". Much better sources:

• Answers' users you know are reliable,
• TMW blogs you know are reliable (sorry to see you leave, Loren Shure!),
• and finally... the documentation :)

[DGM]

If not to make use of the perceived authority of the group account, what other purpose would it serve? I think that's most important when considering that the vast majority of users don't interact enough to know which sources are reliable.

The installation error threads still take the cake, but dormant uncorrected junk answers are still a black eye.

[Stephen23]

"what other purpose would it serve"

Internal processes of large companies do not neccesarily serve any specific purpose. Most likely someone noticed that Answers was a reasonably sucessful forum, and had what is known in the trade as a "bright idea", i.e how TMW could take part... but as with most such ideas, the side-effects and externalities were not really considered.

My five cents worth: the best place to describe the behavior of a product is in the documentation.

[DGM]

I was kind of secretly wondering if some of this material was being dredged in decontextualized form from old newsreader archives or something.

[Walter Roberson]

Users create technical support cases. Solutions are written for the questions. A subset of those are entered into Mathworks internal knowledge base as reference information for support purposes. Support has the option of marking each knowledge base entry for publication in Answers -- using the same data structures, just a matter of whether each one is visible only internally or here as well.

So the support questions that appear here are what appears in the knowledge base. And the challenge is often the original wording of what was asked by users is mostly retained. Not enough effort is going into rewriting them as good Questions.

Rewriting as good Questions can be tricky. Different people think about situations in different ways, so different ways and wordings writing about a situation might engage different people. Rewriting a Question to the way that the question "should" have been asked risks dropping out ways that people are thinking about a question, leaving them unable to recognize it as meeting their needs.

For example, experienced people know that imread() is not responsible for blurring images: the image data might already be blurry or the display process might blur the image, but imread does the best that can be done (though I don't promise that for obscure details of TIFF, that can get pretty complicated.) But people do think of it as imread blurring the image, so having question text asking about imread blurring the image could be useful... as long as it is answered with "it is not imread doing the blurring". Preserving user phrasings instead of writing the question that "should" have been asked can be of benefit at times.

[Walter Roberson]

Years ago on a Cisco newsgroup, two people asked nearly identical questions that would seemingly have identical answers, but I gave them quite different answers and I was right, having diagnosed them as dealing with different situations even though their opening paragraphs could have been pretty much copy-and-pasted. What I had noticed was that their error messages had one space at a point for one of them, but two spaces for the other person. And that pointed to two different causes. So differences in how people ask their questions can be important.

[DGM]

I kind of see it as the purpose of the title to be the broad net, but I admit that's a challenge. Even if there are many ways a question can be posed based on the user's interpretation of the problem, there's no reason a prototype question can't incorporate multiple perspectives/observations. Even if there's a reluctance to edit the natural question, the answer itself can contain enough information to bridge the gap between the question and the solution it poses. Details can be important, but there aren't many of those left here.

Maybe I'm assuming that there was (or should be more) human interaction behind these answers. I suppose it's understandable that there isn't if much of the content is just programmatically exported here. That kind of explains the installation threads.