Well, let’s work it from end to beginning:
Lose the exclamation points. Don’t yell at the user. It’s rude and insulting.
Does the user know what an “image file” is? Do they understand “image” or “file”? Conduct some user testing, but I’m guessing “picture” is more appropriate.
And what is not an image file? Maybe the user mis-selected the file, but they can’t tell, so they’ll assume the app doesn’t work for them. Maybe they selected a bunch of files, but one is mis-named as an image file (wrong extension). Now that have do trial-and-error exhaustively to find out which file is the problem.
The message gives the prescription without giving the problem. Occasionally that’s enough, but probably not here. What if the problem is the user uploaded a MS Word document with nothing but an image pasted in it? What if the problem is the image file is corrupted? What if it’s an obscure format your app doesn’t support? In all cases, you’ve a pissed user, saying “I did select an image file, you moron!!” (users are permitted to yell at the computer; yeah, it’s a double standard).
Maybe okay. Politeness can help, but it can also annoy when it’s the third time the user gets the message and they don’t understand why. And it adds words. In a message box, the more words, the less the user reads. Probably better off without it.
So, take out the problems, and, why, that leaves nothing of the original message.
Here’s the alternative:
”Can’t find picture in [filename].”
Below this you can add secondary diagnostic or prescriptive text (e.g., the formats you support), or it may be better to rely on a link to context-sensitive documentation to help the user troubleshoot.
Here’s another alternative:
Yes, no error message. Instead, filter the selection of files to only include readable image files (e.g., by extension). Okay, you’ll still need the error message for corrupted or mis-named files, but it’ll go a long way to eliminating the problem before it occurs.
To summarize, an error message should:
Only be used when you can’t prevent the error in the first place.
Never yell at the user.
Use the user’s language.
Be specific –provide information from the context.
Describe the problem more than give the prescription.
Be brief, even if it means being terse.
Link to context-sensitive help or troubleshooting documentation.
The usual style guides (e.g., Windows and Apple) provide good advice on writing error messages.