Created attachment 1941097 [details] Example AVIF file that gThumb should be able to display Description of problem: AVIF/AV1 file is not displayed in gThumb Version-Release number of selected component (if applicable): 3.12.2 How reproducible: Always Steps to Reproduce: 1. Open .avif file with gThumb 2. 3. Actual results: Image (sequence) is not displayed Expected results: Image (sequence) is displayed Additional info: According to upstream [1], gThumb supports the AVIF (AV1) format since version 3.11.4 using libheif. However, the executable is not linked to libheif according to: ldd $(which gthumb) | grep -i heif [1] https://gitlab.gnome.org/GNOME/gthumb/-/blob/master/NEWS
I believe the reason for this is that we don't have libheif in Fedora. See also gimp ticket https://bugzilla.redhat.com/show_bug.cgi?id=2164329 that requests the same thing.
Thanks for the quick response. I was looking for libheif and found it. But it turns out it's from RPMFusion Free repo. So, I guess there's a legal issue of some kind preventing inclusion in Fedora? Albeit, since we are talking FSF with regards to gThumb, I'd be surprised.
I guess bug 2164329 comment 3 answers my question. I'll take a look if I can find out why the option of just shipping the free AV1 codec with libheif wasn't considered.
(In reply to Sandro from comment #3) > I guess bug 2164329 comment 3 answers my question. I'll take a look if I can > find out why the option of just shipping the free AV1 codec with libheif > wasn't considered. Thanks! I don't know anything more about this than what bug 2164329 comment 3 says.
I've been following along the libheif packaging discussion on the devel list - thanks for nudging that in the right direction! Now that the libheif package is in Fedora, I was able to enable avif support in gthumb: https://src.fedoraproject.org/rpms/gthumb/c/8401cb9fb81de05f115b39f21ecb033febf0cff1?branch=rawhide
FEDORA-2023-96e0459eec has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-96e0459eec
FEDORA-2023-d27a44e35f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-d27a44e35f
Excellent! Thank you very much. I'll test drive the package as soon as it hist testing.
FEDORA-2023-96e0459eec has been pushed to the Fedora 38 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-96e0459eec See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-d27a44e35f has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d27a44e35f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-d27a44e35f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Installing the updated package with sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-d27a44e35f gives me Problem: package gthumb-1:3.12.2-7.fc37.x86_64 requires libraw.so.20()(64bit), but none of the providers can be installed - cannot install both LibRaw-0.20.2-7.fc37.x86_64 and LibRaw-0.21.1-2.fc38.x86_64 - cannot install the best update candidate for package gthumb-1:3.12.2-5.fc37.x86_64 - problem with installed package LibRaw-0.21.1-2.fc38.x86_64 I have LibRaw-0.21.1-2.fc38.x86_64 installed.
Hang on. Good morning rubber duck. I must have pulled in LibRaw when installing a package from rawhide.
Yep, that looks like a F38 package mixed in :)
Indeed. I pulled that in when upgrading ImageMagick from rawhide. I think that was in the idle hope that this would fix the AV1 issue. Adding '--allowerasing --best' solved it by downgrading. However, since I had the RPMFusion libheif package installed already, I also needed to upgrade that manually: sudo dnf --refresh --enablerepo=updates-testing upgrade libheif While I can open the attached avif file in gThumb, it is not displayed correctly. I only get a pink frame, but no animation or sequence of images. Running 'ldd $(which gthumb)' doesn't show any linking to libheif.
Hm, it works fine in my testing. I downloaded the first image from https://libre-software.net/image/avif-test/ and did `sudo dnf update gthumb --enablerepo=updates-testing` and it shows just fine: https://kalev.fedorapeople.org/gthumb-avif.png I have libheif-1.15.1-2.fc37.x86_64.rpm and gthumb-3.12.2-7.fc37.x86_64.rpm installed. As for linking to libheif, it's /usr/lib64/gthumb/extensions/libcairo_io.so that links to libheif, not the main gthumb binary in /usr/bin.
Hmm. I'm intrigued now. Could be my file is broken, but I doubt that. I got it from a website, but I cannot find it any longer. I ran 'file' on both files: file Pictures/rewire.avif Pictures/rewire.avif: ISO Media, AVIF Image Sequence file Pictures/gthumb-avif.png Pictures/gthumb-avif.png: PNG image data, 1920 x 1200, 8-bit/color RGBA, non-interlaced Your sample file is of a different type than mine. Yours appears to be static, whereas mine is a sequence, webp/gif like animation. I still believe mine should be displayed in gThumb correctly. Interestingly, when right clicking in Nemo it only offers Shotwell as an application for rewire.avif, whereas for gthumb-avif.png it offers the range of image utilities incl. gThumb. Opening rewire.avif in my browser (Brave) it is displayed as an animated sequence.
Just to a void any misunderstanding: gthumb-avif.png that I linked to is NOT an avif file. It's a screenshot to show that it was working for me. The test file I used was https://libre-software.net/wp-content/uploads/AVIF/AVIF%20test%20file%20-%20Your%20browser%20%28software%29%20supports%20AVIF%20%28Quality%2025%29.avif Having said that, I can't get any sequence avifs to load either. With https://github.com/link-u/avif-sample-images/blob/master/star-8bpc.avifs?raw=true for example I just get a generic icon instead of the image which I think must mean a loading error.
(In reply to Kalev Lember from comment #17) > Just to a void any misunderstanding: gthumb-avif.png that I linked to is NOT > an avif file. Thanks for the clarification. I opened the avif file you used in gThumb. It is displayed correctly - also in my browser (Brave). The one remaining difference then is that your file is static, whereas mine is a sequence, animated image. Using file again, I see that yours is actually a HEIF image: file Pictures/avif_test.avif Pictures/avif_test.avif: ISO Media, HEIF Image Maybe best if one of us discusses this with upstream. But I'd also like to see other packages making use of the new Fedora libheif to compare behavior between apps.
For informational/documentation purposes, I also ran 'heif-info' on the two files: heif-info Pictures/avif_test.avif MIME type: image/heif main brand: mif1 compatible brands: mif1, avif, miaf image: 630x420 (id=1), primary color profile: no alpha channel: no depth channel: no metadata: none heif-info Pictures/rewire.avif MIME type: image/avif-sequence main brand: avis compatible brands: avif, avis, msf1, mif1, miaf, MA1B image: 2000x2000 (id=1), primary color profile: nclx alpha channel: yes depth channel: no metadata: none
I have no idea what's going on here, sorry. It could be that libheif doesn't support the avif sequence format, or maybe it's gthumb that is missing the support, or maybe it's the way libheif is compiled for Fedora (with certain plugins missing) that leaves out the sequence format support. I think next would be to take it up with gthumb or libheif upstream who would know how to diagnose it further. We've done the necessary packaging changes to get basic libheif support working at least.
(In reply to Kalev Lember from comment #20) > I have no idea what's going on here, sorry. It could be that libheif doesn't > support the avif sequence format, or maybe it's gthumb that is missing the > support, or maybe it's the way libheif is compiled for Fedora (with certain > plugins missing) that leaves out the sequence format support. Neither do I. But I'll keep digging... I will wait for the new libheif-heic to become available in RPMFusion to see if it makes any difference. It may well be that gThumb does not support animations. > I think next would be to take it up with gthumb or libheif upstream who > would know how to diagnose it further. We've done the necessary packaging > changes to get basic libheif support working at least. I will do that once I tested with libheif-heic. Then we have indeed done everything on our side as far as I can tell. Shall I keep this bug open then or reopen once the update hits stable?
(In reply to Sandro from comment #21) > I will do that once I tested with libheif-heic. Then we have indeed done > everything on our side as far as I can tell. Excellent, thanks! > Shall I keep this bug open then or reopen once the update hits stable? I would close this bug once the update hits stable. I don't think there is anything more to do on the packaging side here for gthumb for now.
I created an issue upstream: https://gitlab.gnome.org/GNOME/gthumb/-/issues/270
FEDORA-2023-96e0459eec has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2023-d27a44e35f has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Sandro from comment #23) > I created an issue upstream: > https://gitlab.gnome.org/GNOME/gthumb/-/issues/270 Thanks! I added myself to CC there.