Can not open PNG or JPG Files in eot
- Inicie sesión ou rexístrese para enviar comentarios
Hello!
I have installed Trisquel as NetInstall using
apt-install gnome-session
and the other commands from the "trisquel gnome instructions" after the installation. However, my Gnome image viewer (eot) now cannot open or even view any JPG or PNG files. I always get in eot the message that the format is unknown. What could be the reason? I think I have installed all the important packages (like libgdk-pixbuf-2.0-0) or is there a command or package that helps that I haven't found yet?
After some research, I tried to check the loaders with; "ls /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-ani.so"
And this was the output;
libpixbufloader-ico.so libpixbufloader-tga.solibpixbufloader-bmp.so libpixbufloader-pnm.so libpixbufloader-tiff.solibpixbufloader-gif.so libpixbufloader-qtif.so libpixbufloader-xbm.solibpixbufloader-icns.so libpixbufloader-svg.so libpixbufloader-xpm.so
Thanks for the help in advance! :)
Ok, apparently the problem only affects images that I downloaded with Abrowser. Because in my internal second hard disk eog can read all jpg and png files. But all png and jpg files I download with Abrowser won't open.... but if I download images with Falkon Browser it works fine... Is this a restriction and maybe a normal behaviour?
Ok, I now have this result with the following command:
file downloadedpic.jpg
downloadedpic.jpg: RIFF (little-endian) data, Web/P image
And if I convert it with Imagemagick like this;
convert downloadedpic.jpg downloadedpic-converted.jpg
the image functions suddenly. So Abrowser downloads the images with the wrong extension or how should I interpret or understand this? Can I change or fix this somehow?
Abrowser does indeed download and save webp images as webp files.
Are you getting a dialogue box at some point while downloading webp images with Falkon for local save? Or does it convert them without asking?
No, it just opens the normal window where I can decide where I want to save the file. I have also noticed that webp files can only be downloaded as webp in the search window (i.e. by right-clicking), but as soon as I right-click to display the file in a new tab and then start to download it there, it is then downloaded as a jpg file.
However, both files cannot be viewed/opened with eog because the format is not recognized.
Try this:
sudo apt install webp
sudo apt install webp-pixbuf-loader
sudo gdk-pixbuf-query-loaders --update-cache
I installed the two first commands successfully, but with the last command I got an error message;
sudo gdk-pixbuf-query-loaders --update-cache
sudo: gdk-pixbuf-query-loaders: command not found
I then tried to install it but it is supposedly already installed;
libgdk-pixbuf2.0-bin is already the latest version (2.42.8+dfsg-1ubuntu0.3).
I then restarted the browser anyway and tried a test run;
Now I can download webp files! But when I open the webp file with a right click in a new tab and want to download it, it is still downloaded as jpg or png (not sure how the format is choosen). But otherwise we have made some progress :)
Are you saying that Abrowser converts the image format? It does not do so here (running GNOME too, but that should make no difference) and I have never heard of such a feature. For instance, if you download https://developers.google.com/static/speed/webp/images/webplogo.webp you end up with an image in a different format? The 'file' command can give it:
$ file webplogo.webp
webplogo.webp: RIFF (little-endian) data, Web/P image
At least on my system, only webp-pixbuf-loader is needed to have eog display WebP images. It takes fewer than 50 kB of disk space.
I gave up GNOME. So many bugs.
Triskel (with KDE Plasma) works beautifully.
The best experience so far.
Hm, well... on the KDE website there is a point called “Customizable” and if you click there on the tab community extensions, the desktop looks almost like GNOME. I could deal/live with that design, but what is the name of this extension, does anyone know by chance because I could not find something like this in the KDE Store yet? I have attached a screenshot so that you know what I mean. :)

Ok, I think I've found something suitable and will try this today or tomorrow :)
https://store.kde.org/p/1464321
https://store.kde.org/p/1633673
Thanks for the help anyway and I'll have a look at what Triskel has to offer.
In this case, there is no bug. webp-pixbuf-loader must be installed to have support for WebP in older versions of GNOME. WebP is supported by default in more recent versions, if I properly understand https://gitlab.gnome.org/GNOME/gnome-build-meta/-/merge_requests/2507
So many bugs and missing backports.
What do you mean by "backports"?
You are hereby backported:
https://trisquel.info/en/forum/can-not-open-png-or-jpg-files-eot#comment-179443
Mind the loop.
Lol.
I have to say that I am very satisfied and positively surprised with the KDE Plasma Desktop. You can really set and customize everything individually. That's absolutely amazing. I always thought it would be something like the MATE desktop, and I didn't like MATE at all, and LXDE wasn't for me either. However, I probably had more prejudices about KDE somehow... therefore many thanks for the recommendation :)
But also with Triskel, I have the same problem; that I can't download webp or PNG/JPG files with Abrowser. But the commands of icarolongo have at least solved the webp issue in KDE as well as in GNOME before.
So the same problem as with the GNOME desktop is also with the KDE Desktop (or it is actually more of an Abrowser problem), which is not really annoying because if I have to download a graphic, I just have to use the Falkon browser, so it is not a real problem but somehow a little troublesome... anyway, I can overlook it.
Thanks again for the recommendation, I'm currently trying to create a nice "latte dock" :D lol...
I just realized that the image download problem seems to be due to my search engine. I tend to use Brave search because it has a pretty acceptable AI and delivers very good search results. I have now also tested the whole thing/issue with Duckduckgo and Qwant and everything works perfectly. Hm... so Brave also restricts my freedom to download images in this case... that's fascinating and also kind of disappointing... :/
As much as the desktop environment should make no difference, neither should the search engine configured in the Web browser... unless you imply that the problem only occurs when you download an image from the search results. Do you?
You do not precisely describe how you try to download a specific WebP image that ends up into another format. If you do, we could try the same on our systems and investigate. For a start, please reply to https://trisquel.info/forum/can-not-open-png-or-jpg-files-eot#comment-179445 by telling us in what Web browser you click on the link I gave and show us the format of the downloaded file, as reported by 'file'.
Well, in most cases I search for images on the internet with a search engine and since I tend to use Brave search, as already mentioned, I have used Brave search in combination with Abrowser without thinking or even suspecting that this would cause problems.
And if you go to brave search via the Abrowser and open an image (in my case simply the first image https://search.brave.com/images?q=chromium%20logo - from the wikepedia mobile entry) with a new tab and then try to download it, the file that was previously a webp image is suddenly a png image that doesn't work after the download.
I mean this link for example;
https://imgs.search.brave.com/nEyIqQ9nbiRdwZ60OoYhCMcoRcEf1BYV2m5g0jRJlpY/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly91cGxv/YWQud2lraW1lZGlh/Lm9yZy93aWtpcGVk/aWEvY29tbW9ucy8y/LzI4L0No...
But as I said before it works fine with (at least) the Falkon Browser. I can't say what the problem is, but it seems to affect all webp images (of course only with the brave search and with Abrowser) which suddenly become defective jpg or png files as soon as you open them in a new tab to download them from there.
I hope I have described the issue understandably enough, otherwise please just ask what you would like to know :)
OK. Then, I believe the problem does indeed relate to the image search service you use (what was impossible to understand before in the thread, since you were not talking about search results). search.brave.com probably converts images it crawls to store them in a common format, maybe not requiring as many CPU cycles to display. In the case you mention, the SVG image https://upload.wikimedia.org/wikipedia/commons/2/28/Chromium_Logo.svg is stored on search.brave.com as as the PNG https://imgs.search.brave.com/nEyIqQ9nbiRdwZ60OoYhCMcoRcEf1BYV2m5g0jRJlpY/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly91cGxv/YWQud2lraW1lZGlh/Lm9yZy93aWtpcGVk/aWEvY29tbW9ucy8y/LzI4L0No... that is shown if you right-click on it and ask for displaying the image in a new tab. You had better access the source image (the link behind the image), which should always be of better quality.
Well, I had downloaded images and all of them did not work and I thought at first that it was the image viewer because I only did a minimal installation of Trisquel Netinstall. So my first thought was; something is missing for it to work.
But then I realized that the problem only seems to be with pictures that I downloaded from the internet and not with old pictures that I already have stored on a second hard drive.
Now I think that the problem is probably with Abrowser, because the same approach works fine in Falkon Browser, so with another browser you can download all the images that you can't download with Abrowser (of course with Brave search). But since Brave search is not really free, I can understand that it is probably related to that.
Despite the extensions in their file names, the images stored on search.brave.com are not PNG files. Here are the first eight bytes of Chromium's logo there:
$ od -cN 8 Chromium_Logo.png
0000000 R I F F ( V \0 \0
0000010
That identifies the Resource Interchange File Format (RIFF): https://en.wikipedia.org/wiki/Resource_Interchange_File_Format
In fact, it is a WebP image. That format indeed uses RIFF as a container. The next eight bytes show it:
$ od -cN 16 Chromium_Logo.png
0000000 R I F F ( V \0 \0 W E B P V P 8 X
0000020
And file obviously reaches the same conclusion:
$ file Chromium_Logo.png
Chromium_Logo.png: RIFF (little-endian) data, Web/P image
PNG files always start with these eight bytes according to https://datatracker.ietf.org/doc/html/rfc2083#page-77 (the standard defining PNG):
0000000 211 P N G \r \n 032 \n
0000010
I do not understand why search.brave.com ends the name of page with the image opened with ".png" at the end, since the format is actually WebP. Is Falcon really doing the conversion, i.e., is the file command reporting the PNG format when Falcon downloaded the image from search.brave.com?
Yes, with the Falkon browser I can download this file
as a PNG image and then open it without any issues. Unfortunately, this does not work with the Abrowser. But from my point of view, it is not a significant problem. It's just a bit annoying to have to change the browser (or the search engine) every time to be able to download some images, but that's a small matter (or just a view clicks) from my point of view.
But this raises the question of what is more in the spirit of freedom; do I want to download a file as it is (in which case it would be unusable for the average user) or do I want a browser to convert and recognize it so that I can then use the download.
It would also be interesting to find out where the issue occurs else or whether it is really only limited to the Brave/Abrowser combination. But I haven't noticed anything else so far.
In mate I use gThumb as my default image viewer and even when Abrowser incorrectly sets the extension as png, gThumb can handle the file just fine, I suppose there is an issue on certain scenarios where Firefox/Abrowser doesn't handle/detect correctly the mimetype, nonetheless maybe eog can't handle webp just yet as viewnior can't.
OK. I consider Brave's behavior weird: why would a Web browser convert images when the extension in its name is wrong?
It is not the browser that is doing this - It is the web server. You can see that the web server is serving the file in a different format when the browser advertises support for Web/P.
#1:
$ wget "https://imgs.search.brave.com/nEyIqQ9nbiRdwZ60OoYhCMcoRcEf1BYV2m5g0jRJlpY/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly91cGxv/YWQud2lraW1lZGlh/Lm9yZy93aWtpcGVk/aWEvY29tbW9ucy8y/LzI4L0Nocm9taXVt/X0xvZ28uc3Zn" -o test
$ file X0xvZ28uc3Zn
X0xvZ28uc3Zn: PNG image data, 860 x 860, 8-bit/color RGBA, non-interlaced
$ rm X0xvZ28uc3Zn
#1: Now, let's do that again but adding a header to the request saying that we support Web/P:
$ wget --header="Accept: image/webp,image/apng,image/*,*/*;q=0.8" "https://imgs.search.brave.com/nEyIqQ9nbiRdwZ60OoYhCMcoRcEf1BYV2m5g0jRJlpY/rs:fit:860:0:0:0/g:ce/aHR0cHM6Ly91cGxv/YWQud2lraW1lZGlh/Lm9yZy93aWtpcGVk/aWEvY29tbW9ucy8y/LzI4L0Nocm9taXVt/X0xvZ28uc3Zn"
$ file X0xvZ28uc3Zn
X0xvZ28uc3Zn: RIFF (little-endian) data, Web/P image
$ rm X0xvZ28uc3Zn
So there's your difference: The web server itself transparently serves it in the Web/P file format when the browser tells the web server "Hey, I support Web/P" and as a PNG when it doesn't. In this way the web server operator gets the ability to serve smaller files when the browser supports it while also not causing problems for other browsers that don't support Web/P (or at least don't advertise it.)
So now you can stop blaming the web browser for "converting" it; only for a) supporting the Web/P file format and b) advertising that fact to web servers. :)
This also shows that you cannot rely on a file extension. I could rename the file to X0xvZ28uc3Zn.png but that would not make it be a PNG if the web server sent it as a Web/P. I could also rename it to X0xvZ28uc3Zn.odt it would not become an OpenOffice document. You have to check what's in the file. :)
(EDIT: Since I list Web/P first in the header, technically my header says "I *prefer* WebP", not that I "support" Web/P but the point remains that the browser isn't doing any file format conversions.) Falkon like either doesn't support Web/P or has a different priority list in the accept header. Looking into that would require more research that I leave as an exercise for the reader.
The accept header is also used in other contexts too. gnu.org uses it to decide what language to serve web pages in.
Example: Visit https://www.gnu.org/philosophy/free-sw.html
Then change the preferred language order in your browser and try again. If there's a translation available in the preferred language, reloading the page after changing the language order should show that instead.
Thank you for your great explanations!
This also shows that you cannot rely on a file extension.
Sure... but it remains weird to serve a WebP image whose name ends with ".png".