Bug 498650

I suspect this is because dimg's heif loader only checks the file extensions for `.heif`... and I don't have other image loader plugins installed.

heif has nothing to do with avif.

The work around to rename file force digiKam to use the KImageIO plugin to load image through QImage.

Did you have the avif type mime in the list of the setup page :

https://docs.digikam.org/en/setup_application/views_settings.html#mime-types-settings

Gilles Caulier

digiKam also checks the magic bytes, e.g. for HEIF images:

    if (
        (memcmp(&header.data()[4], "ftypheic", 8) == 0) ||
        (memcmp(&header.data()[4], "ftypheix", 8) == 0) ||
        (memcmp(&header.data()[4], "ftypmif1", 8) == 0)
       )

Unfortunately your log is too short and does not contain the magic bytes check.

Another reason could be that you do not have the KImageFormat plugins installed.

Please provide the file.


Maik

A test here with avif and heif images whose extensions are reversed shows that digiKam always recognizes the correct file type.

Maik

avif files are AV1 encode inside heif container, or was I mistaken?

I don't have _any_ KImage or QImage imageformat plugins installed.

Without the KImageFormat plugins, digiKam cannot load AVIF images or other "modern" formats such as WebP. It is not intended that our HEIF loader will do this job as an alternative.

Maik

(In reply to Maik Qualmann from comment #6)
> Without the KImageFormat plugins, digiKam cannot load AVIF images or other
> "modern" formats such as WebP. It is not intended that our HEIF loader will
> do this job as an alternative.
> 
> Maik

I see. I think I should clarify that once I had the plugins, `.avif` files load fine.

It's just curious that even without the plugins, `.avif` files _can_ be loaded as long as they are named `.heif`. Why leave this capability on the table if it works?

The heif is container where avif data can be hosted. By chance your libheif is compiled with avif support (optional) and libheif is able to extract the data.

heif and avif are handled by 2 separated plugins. Some linux distro ban libheif due to patents stuff...

Gilles Caulier

in that case, can the internal libheif based loader at least try loading the avif file? if libheif isn't compiled with avif support, then fine, we give up. it couldn't hurt to at least try?

As i already say, if libheif is not present in a Linux distro, you will lost HEIF and AVIF support. There is no restriction with AVIF plugin. So 2 separate loaders is better.

Gilles Caulier

I don't get this argument? If I don't have the avif plugin installed, I don't get avif support either.

OTOH if I do have an avif capable libheif installed and digikam is not using it to loader avif files, that's wasted potential. I don't understand why digikam can't at least try loading avif files with libheif.

I do want to understand your position here. Is the problem here that you don't want to have multiple plugins supporting the same format? So you don't have to think about plugin priorities, etc.?

Well, adding the magic bytes "ftypavif" as a supported file type to the HEIF loader would be no problem. However, in digiKam the respective image loader decides which mime type it is. Here we would then store the AVIF file in digiKam as a HEIF file in the DB. So we would have to create another workaround so that this image is treated as an AVIF mime type. Sorry, we should definitely make a clear separation of the image loaders here. I already wrote that without the KImageFormat plugins you cannot load many other modern formats (WebP, JXL, etc.).

Maik