Image import doesn't allow for .jpeg extension

• Oct 25, 2013 - 12:23
Type
Functional
Severity
S4 - Minor
Status
closed
Project
MuseScore

Drag and drop of an image with an extension of .jpeg fails
unknown.png
Renaming the file to have a .jpg extension and it can get imported.

Culprit seems to be in file ...mscore/dragdrop.cpp, method ScoreView::dragEnterEvent() which allows for .svg, .jpg, .png, .gif and .xpm extensions.

Another occurence is in file ...mscore/file.cpp, method MuseScore::addImage(), which only allows for .svg, .jpg, .png and .xpm extensions.
Yet another is in file ...mscore/Palette.cpp, method palette::dragEnterEvent(), which only allows for .svg, .jpg, .png and .xpm extensions.

This report stems from http://musescore.org/en/node/23284, picture taken from there, reported for 178bfe6 on Win 8 pro

Extending these methods to also allow .jpeg should be easy enough?
And while at it, also extending MuseScore::addImage() and Palette::dragEnterEvent(), to allow .gif too?

Comments

• Oct 25, 2013 - 15:06

Reg. the error message: it should better talk about "unknown extension" or "unknown type" rather than "unknown format", as MuseScore does know the JPEG format quite well.

I've opted for "unknown type" as that best matches the error FILE_UNKNOWN_TYPE

Reply

• Oct 26, 2013 - 10:08

Are we just lacking the right lib, like qgif.dll?
We have a dll for jpeg, mng (I guess that includes png), svg and tiff

So could we support .mng (apparently some sort of animanated png) and .tif, .tiff (by just adding them to the list of supported extensions), but not .gif? I see .gif being allowed for wallpapers, but it doesn't seem to work there either.

Reply

• Oct 26, 2013 - 14:19

We need to put a limit somewhere... According to wikipedia , JPG files can have an extension (I believe this is the right word btw, and not file type) of .jpg and .jpeg, though .jpe, .jfif and .jif are also used. Should we support all these options?
MNG, TIFF, GIF, XPM we can probably find other exotic image formats... and of course, animated version of them, and then what do we do when we print them? or save as PNG?

I believe that "less is more". I propose to

* support only JPG and PNG (eventually with jpeg extension) and of course SVG for vector graphics
* remove the support for GIF and XPM.
* remove GIF support in wallpapers

Reply

• Oct 26, 2013 - 15:30

I'm fine with removing .gif and .xpm, esp as gif doesn't work anyway and either never were documented to be supported. I'd allow .jpg and .jpeg, but none of the other JPEG extensions, they are pretty exotic IMHO.
Want me to send in a pull request for the .gif and .xpm removal?
Not sure though whether the qtiff.dll would still be needed or how to remove it.
Windows calls it 'type', so I'd go with that.

Reply

• Oct 26, 2013 - 16:30

A PR would be cool. On top of your current one would be great. And even more, it would be even better if you could at least compile the code and test it before pushing :)

Reply

• Oct 26, 2013 - 17:07

I don't have a build environment and won't have one short term. I know that it'd be better...
The gif problem though must exist since quite while, my addition and tests just uncovered it :-)

MusicXML seems to support gif and tiff (see ...mscore/schema/musicxml.xsd), so maybe we shouldn't remove tiff but add it instead (.tif and .tiff) and make .gif work?

Reply

• Oct 27, 2013 - 08:07

While you may be right reg. less is more, if we have to support tiff and gif for MusicXML anyway, we'd basically get it for free in the normal image-, background- and wallpaper import and maybe even export, we'd just have to enable it there and fix the gif part, which for MusicXML we'd have to fix anyway.
What does Leon have to say about the MusicXML part?

Reply