Hello, I’m getting back to you with a question about an error that occurred when using the APPLE Files Type HEIC.
I have installed libheif in the version Fedora 35 but unfortunately I have only partial success in using it.
Nautilus shows the thumbs but not the previews
The new version of gThumb 3.12 can only display the thumbs, but not the preview in the canvas.
Also Gimp can show the thumbs in the filebrowser but not open the file.
I am a little perplexed.
Kind regards
Fedora 35 is still in branched – testing. Beta is not out yet.
Please file a bug on your problems.
libheif is a rpmfusion-free package, not a fedora one. So it seems to add least register a gdk-pixbuf-2.0 plugin. So
Any indication when run nautilus from terminal ?
Please report a bug to bugzilla.rpmfusion.org if any issue related to the package.
Thanks in advance.
No there are no error messages when I run Nautilus from the terminal.
Same on Fedora 34, nothing on the nautilus command line, nothing in journalctl. Eye of Gnome aka ImageViewer shows the images (albeit without metadata) and the Nautilus Thumbnails work.
Others like Okular, Shotwell and the Nautilus preview don’t recognize the file format.
I guess Apple gave us some extra homework to integrate their file format fully into the open desktop.
Thanks for the feedback
Regardless of the fact that Apple cooks its own soup, there are still standards that should be adhered to.
It is not a problem of Fedora.X that this format can not be processed 100%, because this announcement gThumb 3.12 Heif Support does not apply.
On my second machine with Ubuntu 20.4 LTS and gThumb 3.12 it also does not work under Fedora34 and 35. The problem is unfortunately system-wide significant, because under Digikam the files are read in the current version although extremely slowly and without Exif data. But much more interesting is that an older version of Digikam’s ShowFoto can be used including Exif metadata.
Many greetings
It’s unlikely that the fedora gthumb package will gain HEIF support given the required library is in rpmfusion-free.
What could be done is for someone interested it to submit a gthumb-freeworld alternate build with HEIF support enabled and maintain it in rpmfusion.
Another way would be to choose another thumbnail provider (or to use a gthumbnail provider using gdk-pixbuf infrastructure plugin).
I hope this helps…
Thank you very much for the help.
Currently, unfortunately, even the final version of Fedora35 does not have HEIF/HEIC support.
Nautilus shows the thumbs but the preview via the spacebar does not work “unknown format” as error message.
ghtumb only shows the thumbs without exif and preview and also can’t convert to JPEG etc.
The Gnome 41 image viewer shows the thumbs and the preview correctly but without Exif.
Remains only the terminal https://linuxnightly.com/convert-heif-images-to-jpg-or-png-on-linux/
Unfortunately this is not a problem of Fedora but a general one, because also the other Linuxdistros can do relatively little to nothing with the format although already years available.
Even KDE Digikam had the function and currently this is again only rudimentary available.
It is unfortunately so that Apple remains generally rather a problem case under Linux and I will have to orient myself evenly around or adapt my workflow because there is tinkering on highest level.
Kind regards from Vienna
Translated
You are complaining about wanting FOSS support for a proprietary file system. It took many years before ntfs support was reasonably reliable for both read and write. Apple is now playing the same game as Microsoft has in the past and they can with a proprietary file system…
If you want support sooner then volunteer to assist in developing that support. Otherwise you will have to be patient while the existing developers work on a reliable support for apple’s file system.
HEIF is not a file system… It’s an image container format. And although Apple has been an early adopter and the biggest user of the standard, it is not an “Apple format”. It’s an MPEG standard.
My error,
I had not researched it and the reference to apple led me to interpret it as an apple development.
The OP has commented on several tools (nautilus, gnome image viewer, gthumb) that cannot fully access the images using this standard.
It is my understanding from a quick perusal that heif is different than jpeg, mpeg, etc. so it is understandable that access is different. Tools that work well with a jpeg image would need altered to work with an heif image so those maintainers/developers would need to alter their tools to read the images.
My suggestion to assist in development or to be patient still stands though. Volunteers who develop & maintain FOSS software have limited time and often work day jobs and do development in their free time after job, family, and health are taken care of.
The available choices are assist, or be patient.
Good morning, I must apologize and just realize that my objection to the topic seems to have been misunderstood.
I am not a developer but a user and the statement that under Fedora35 the HEIF support is only rudimentary is not a criticism of Fedora.
This problem concerns not only Fedora but generally all Linux distributions and also Windows where it can be however system far post-installed.
The topic is closed for me because not solvable.
Best regards MG
Translated
Is there a reason libheif can not be in the main repo?
@dreua
I think the post of @computersavvy already contains the answer to your question (and the reasons).
The license of libheif seems to be ok for Fedora, but it is a lot of work to fulfill the high quality requirements of the Fedora main repos as these have to deliver a stable operating system. This includes all software contained.
The development, testing and maintenance efforts necessary to ensure this quality are huge, and someone has to take the responsibility of it. This is no one time task. And all these issues also apply to any depenency of libheif.
This thread itself illustrates what happens if no one is in charge to ensure these quality standards 
Because Fedora doesn’t ship patent-encumbered software in its main repos:
libheif is LGPL
As explained in the link I have posted above, software patents are different from copyright. There are many software which have a suitable license to be included in main repos but they are placed in RPM Fusion repos because they are patent encumbered: Some popular examples are mpd (GPLv2+), mpv (GPLv2+ and LGPLv2+), ffmpeg (GPLv3+), etc.
I’m aware of licenses and patents and I’m a packager myself so I know what that means, too. Let me rephrase my question to be more specific: Is libheif patent encumbered in a way that makes it incompatible with the main repos? (Ideally with sources)
I just asked whether libheif could be auto-installed once rpmfusion is enabled over at rpmfusion’s bugzilla. I believe that would be one step towards better “HEIF Support”.
That doesn’t really seem likely. Enabling a repo shouldn’t automatically install image libraries.