Page 1 of 1

XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Thu Nov 23, 2023 3:04 pm
by cocomax
XnViewMP 1.6.2 _linux_64 not open / read /load avif file. Whi ?

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Wed Mar 06, 2024 12:05 pm
by Danny
+1 on Fedora 39

I've tried the TGZ, the AppImage and the Flatpak. Neither of them seem to support AVIF in any shape or form.

It's supposed to work: viewtopic.php?t=46266 but doesn't for me.

I've installed both libheif 1.17.5 and libavif 0.11.1 on the system. A

Code: Select all

ldd XnView
on v1.6.5 doesn't even list anything about HEIF or AVIF. Neither does a file search in the program folder.

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Thu Mar 07, 2024 4:37 pm
by xnview
do you have libheif.so?

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Sat Mar 09, 2024 6:56 pm
by Danny
Yes, installed:

Code: Select all

libheif.x86_64 : 1.17.5-1.fc38
I'm trying to use the Flatpak version though, so not quite sure how relevant that is.

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Sat Mar 09, 2024 7:29 pm
by cday
Danny wrote: Sat Mar 09, 2024 6:56 pm Yes, installed:

Code: Select all

libheif.x86_64 : 1.17.5-1.fc38
I'm trying to use the Flatpak version though, so not quite sure how relevant that is.
Please note that the Flatpak download is often not the latest version, the current download version is indicated on their download page... :(

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Thu Mar 14, 2024 10:00 am
by Danny
cday wrote: Sat Mar 09, 2024 7:29 pm
Danny wrote: Sat Mar 09, 2024 6:56 pm Yes, installed:

Code: Select all

libheif.x86_64 : 1.17.5-1.fc38
I'm trying to use the Flatpak version though, so not quite sure how relevant that is.
Please note that the Flatpak download is often not the latest version, the current download version is indicated on their download page... :(
See my post above. Even the one in the TGZ doesn't support AVIF.

Here's the full output of ldd on Fedora 38 for v1.6.5:

Code: Select all

	linux-vdso.so.1 (0x00007fff368ce000)
	liblibraw.so.1 => not found
	libmdk.so.0 => not found
	libc++.so.1 => not found
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fdeff6e8000)
	libX11.so.6 => /lib64/libX11.so.6 (0x00007fdeff5a1000)
	libQt5MultimediaWidgets.so.5 => not found
	libQt5PrintSupport.so.5 => /lib64/libQt5PrintSupport.so.5 (0x00007fdeff526000)
	libQt5Svg.so.5 => /lib64/libQt5Svg.so.5 (0x00007fdeff4c9000)
	libQt5QuickWidgets.so.5 => /lib64/libQt5QuickWidgets.so.5 (0x00007fdeff4af000)
	libQt5Widgets.so.5 => /lib64/libQt5Widgets.so.5 (0x00007fdefec00000)
	libQt5Multimedia.so.5 => not found
	libQt5X11Extras.so.5 => /lib64/libQt5X11Extras.so.5 (0x00007fdeff4a6000)
	libQt5Gui.so.5 => /lib64/libQt5Gui.so.5 (0x00007fdefe400000)
	libQt5Qml.so.5 => /lib64/libQt5Qml.so.5 (0x00007fdefde00000)
	libQt5Network.so.5 => /lib64/libQt5Network.so.5 (0x00007fdefea46000)
	libQt5Concurrent.so.5 => /lib64/libQt5Concurrent.so.5 (0x00007fdeff49d000)
	libQt5Xml.so.5 => /lib64/libQt5Xml.so.5 (0x00007fdeff455000)
	libQt5Core.so.5 => /lib64/libQt5Core.so.5 (0x00007fdefd800000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdeff44e000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fdeff36d000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fdeff349000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fdefd622000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fdeff707000)
	libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fdeff31e000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fdefd200000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fdefe3e6000)
	libQt5Quick.so.5 => /lib64/libQt5Quick.so.5 (0x00007fdefcc00000)
	libGL.so.1 => /lib64/libGL.so.1 (0x00007fdefe35f000)
	libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fdefe326000)
	libharfbuzz.so.0 => /lib64/libharfbuzz.so.0 (0x00007fdefd526000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007fdefe2d0000)
	libproxy.so.1 => /lib64/libproxy.so.1 (0x00007fdefe2af000)
	libssl.so.3 => /lib64/libssl.so.3 (0x00007fdefd483000)
	libcrypto.so.3 => /lib64/libcrypto.so.3 (0x00007fdefc600000)
	libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fdefcb19000)
	libdouble-conversion.so.3 => /lib64/libdouble-conversion.so.3 (0x00007fdefddea000)
	libicui18n.so.72 => /lib64/libicui18n.so.72 (0x00007fdefc200000)
	libicuuc.so.72 => /lib64/libicuuc.so.72 (0x00007fdefbe00000)
	libpcre2-16.so.0 => /lib64/libpcre2-16.so.0 (0x00007fdefca8b000)
	libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fdefc544000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fdefc0b7000)
	libXau.so.6 => /lib64/libXau.so.6 (0x00007fdeff310000)
	libQt5QmlModels.so.5 => /lib64/libQt5QmlModels.so.5 (0x00007fdefc028000)
	libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fdefddb7000)
	libXext.so.6 => /lib64/libXext.so.6 (0x00007fdefdda3000)
	libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fdefbd48000)
	libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fdefbc78000)
	libgraphite2.so.3 => /lib64/libgraphite2.so.3 (0x00007fdefdd82000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007fdefbb9f000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007fdefd46b000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007fdefea3f000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007fdefd45b000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007fdefe2a8000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fdefd1ee000)
	libcap.so.2 => /lib64/libcap.so.2 (0x00007fdefdd78000)
	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fdefd1bb000)
	liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fdefca69000)
	libicudata.so.72 => /lib64/libicudata.so.72 (0x00007fdef9c00000)
	libpcre2-8.so.0 => /lib64/libpcre2-8.so.0 (0x00007fdefbb05000)
	libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fdefca55000)
	libbrotlidec.so.1 => /lib64/libbrotlidec.so.1 (0x00007fdefca48000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007fdefbad8000)
	libbrotlicommon.so.1 => /lib64/libbrotlicommon.so.1 (0x00007fdefc005000)
As you can see, it doesn't even try to load anything AVIF like libavif or libheif. So my guess is that the build process for the Linux version hasn't been updated yet to actually deploy AVIF support.

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Thu Mar 14, 2024 2:05 pm
by xnview
Danny wrote: Thu Mar 14, 2024 10:00 am See my post above. Even the one in the TGZ doesn't support AVIF.
Please post the avif that you try to load?
As you can see, it doesn't even try to load anything AVIF like libavif or libheif. So my guess is that the build process for the Linux version hasn't been updated yet to actually deploy AVIF support.
libheif is loaded dynamically so doesn't appear in ldd

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Thu Mar 14, 2024 3:24 pm
by Danny
File doesn't matter, it doesn't list anything about AVIF in save menus either. Could be literally any file off the web.

I tried attaching the XnView logo that I've just downloaded from your profile PNG picture and converted using

Code: Select all

avifenc xnview.png -o xnview.avif
, but it wouldn't let me even after adding .png to the filename Which files are allowed?

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Fri Mar 15, 2024 7:53 am
by xnview
do you have /lib64/libheif.so?

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Fri Mar 15, 2024 8:52 am
by Danny
I have these from libheif according to a DNF repoquery:

Code: Select all

/usr/lib/libheif.so.1
/usr/lib/libheif.so.1.17.5
/usr/lib/libheif/libheif-rav1e.so
/usr/lib/libheif/libheif-svtenc.so
/usr/lib64/libheif.so.1
/usr/lib64/libheif.so.1.17.5
/usr/lib64/libheif/libheif-rav1e.so
/usr/lib64/libheif/libheif-svtenc.so

Code: Select all

/usr/lib64/libheif.so.1
is a symbolic link which points to

Code: Select all

libheif.so.1.17.5
. But there are actually no libheif files inside /usr/lib/, only /usr/lib64/. A reinstall didn't change that, so I guess it's on purpose.

Then there are these from libavif:

Code: Select all

/usr/lib64/libavif.so.15
/usr/lib64/libavif.so.15.0.1
/usr/share/thumbnailers/avif.thumbnailer
/usr/lib/libavif.so.15
/usr/lib/libavif.so.15.0.1
/usr/share/thumbnailers/avif.thumbnailer

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Fri Mar 15, 2024 10:09 am
by Danny
So an strace with a grep on libheif reveals the following:

Code: Select all

openat(AT_FDCWD, "/home/danny/Downloads/XnViewMP-linux-x64/XnView/lib/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/home/danny/Downloads/XnViewMP-linux-x64/XnView/Plugins/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "glibc-hwcaps/x86-64-v3/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "glibc-hwcaps/x86-64-v2/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/lib64/glibc-hwcaps/x86-64-v3/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/lib64/glibc-hwcaps/x86-64-v2/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/lib64/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/usr/lib64/glibc-hwcaps/x86-64-v3/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/usr/lib64/glibc-hwcaps/x86-64-v2/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/usr/lib64/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/home/danny/Downloads/XnViewMP-linux-x64/XnView/lib/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/home/danny/Downloads/XnViewMP-linux-x64/XnView/Plugins/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "glibc-hwcaps/x86-64-v3/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "glibc-hwcaps/x86-64-v2/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/lib64/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
openat(AT_FDCWD, "/usr/lib64/libheif.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (File or folder not found)
Problem appears to be the filename. If I copy my "libheif.so.1.17.5" to "XnView/lib/libheif.so", it works.

You should really switch to the .1 notation of the filenames in general, because specifying the major version is probably a good idea. Debian works that way, too: https://packages.debian.org/search?lang ... ds=libheif

The "libheif.so" file without the .1 at the end is actually only contained in the -dev package there, too, as you can see. Normal (non-dev) users won't have that installed and shouldn't have to either.

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Fri Mar 15, 2024 3:17 pm
by xnview
Danny wrote: Fri Mar 15, 2024 10:09 am The "libheif.so" file without the .1 at the end is actually only contained in the -dev package there, too, as you can see.
ok, on some system it's libheif.so and some others libheif.so.1

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Mon Mar 18, 2024 11:32 am
by Danny
@Mods: can we move this to the "reproduced" forum then, please?

Re: XnViewMP 1.6.2 _linux_64 not open / read /load avif file

Posted: Fri Jul 05, 2024 9:25 am
by Danny
Ok, just for the record: looking for

Code: Select all

libheif.so
is wrong¹ for probably all modern distros. Certainly for Debian and Fedora¹, as demonstrated. The program should look for

Code: Select all

libheif.so.1
instead. The number at the end is basically the major version of the lib. It should only be omitted during development, because it always points to the latest dev version from the devel package (that users won't have installed). In a release, you ought to use the versioned file name.

¹ https://docs.fedoraproject.org/en-US/pa ... e_handling

The Flatpak required a workaround for this mistake, too.