GNOME Bugzilla – Bug 764468
QImage qimg format images are not displayed by eog
Last modified: 2016-04-28 16:54:19 UTC
Created attachment 325171 [details] qimg not viewed by eye More & more images on the net are in QImage format. If I download/save one to local file, it has no extension. Instead they begin with somewhat non-standard main-qimg- In my file-manager nautilus they appear with a green-music-page symbol, not a thumbnail. Sadly, EOG does not yet open these images to view ("unrecognised image file format"). How frustrating.
(In reply to I_d'na from comment #0) > Created attachment 325171 [details] > qimg not viewed by eye > > More & more images on the net are in QImage format. Considering that I haven't heard of that format before and even Google doesn't know anything about it, I tend to doubt that. > If I download/save one to local file, it has no extension. Instead they > begin with somewhat non-standard main-qimg- > In my file-manager nautilus they appear with a green-music-page symbol, not > a thumbnail. > > Sadly, EOG does not yet open these images to view ("unrecognised image file > format"). eog doesn't implement format support on its own but relies on gdk-pixbuf for image decoding. However, I think this is more likely gvfs being unable to recognize the file type without a file extension. Can you try the identify tool from ImageMagick on your file to get the real file type?
Created attachment 326906 [details] example of typical qimg file from quora.com example of qimg file as .tar since otherwise invalid file type no pass
Created attachment 326908 [details] tar 'd example of Qt qimg image file
Thank you for your attention. These files have utterly (incomprehensible) nonstandard naming convention e.g. this "main-qimg-707ba2c608a9c315f50936e2650e029c" which I've chosen randomly from quora.com I can't attach it raw, bugzilla objects to nonstandard format, so I've .tar 'd it attachment 326908 [details] "example of typical qimg file from quora.com" no pass q.v. (having problems with bugzilla collision..) try to open it with imageMagick, it fails: ~ display "/media/username/whatever/main-qimg-707ba2c608a9c315f50936e2650e029c" display.im6: no decode delegate for this image format `/media/username/whatever/main-qimg-707ba2c608a9c315f50936e2650e029c' @ error/constitute.c/ReadImage/544. however, it is a web format & it will open in e.g. current chromium-browser. It's a Qt thingie, doing their own ambitious thing quietly in darkened rooms: http://doc.qt.io/qt-4.8/qimage.html I feel that Someone needs to take the developers (wherever thay are) in hand and politely ask them to 1) follow everyone else's normal convention, e.g. xxxxxx.qimg (which means they already have a compatibility problem) 2) let other concerned image projects know what (t.H.) they are up to instead of progressing in glorious isolation. Who is that Someone? They ignored me.
Interesting that your ImageMagick doesn't recognize the format: main-qimg-707ba2c608a9c315f50936e2650e029c WEBP 485x485 485x485+0+0 8-bit sRGB 22KB 0.000u 0:00.000 So, yeah this is no obscure QImage format but actually Google's WebP without an appropriate extension, which also explains why it shows in Chrome. That also makes your bug a duplicate of bug 700751, as there is no "official" support for WebP in GdkPixbuf right now. However there's a plugin for GdkPixbuf linked in that bug that should make it work (didn't try though). See also here: https://bugs.chromium.org/p/webp/issues/detail?id=227 Qt's QImage is not image format on its own but a C++ class that is in a way comparable to GdkPixbuf. --- Thanks for taking the time to report this. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 700751 ***