HEIF Support in Fedora 35

No there are no error messages when I run Nautilus from the terminal.

1 Like

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.

1 Like

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…

1 Like

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

2 Likes

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.

1 Like

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.

2 Likes

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.

1 Like

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

1 Like

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 :wink:

Because Fedora doesn’t ship patent-encumbered software in its main repos:

https://fedoraproject.org/wiki/Software_Patents

libheif is LGPL :wink:

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.

1 Like

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)

1 Like

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.

I think that is the case.

HEIF is a image format using HEVC image coding for the best compression ratios.
libheif uses libde265 for the actual image decoding and x265 for encoding.
Alternative codecs for, e.g., AVC and JPEG can be provided as plugins.

libde265 is an open source implementation of the H.265 video codec.
It is written from scratch for simplicity and efficiency. Its simple
API makes it easy to integrate it into other software.

H.265 is pattent cant be on Fedora

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.

we also could think in a imagemagick-freeworld-7.x.x