displaying images still fails since version > 1.15.1

Hey.

I think #933 was not fully fixed by #914.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1041242:

Since 1.16.2 displaying images works again with eog, but still fails with e.g. geeqie.

There's a branch based upon 1.16.2, with the patch from #914 cherry-picked, but building the package with that still causes geeqie to fail:

$ geeqie 
warning: heif reader error: Unsupported feature: Unsupported codec

warning: heif reader error: Color profile does not exist: Unspecified

warning: heif reader error: Unsupported feature: Unsupported codec

Any ideas?

Thanks, Chris.

Possibly a bug in "geeqie" - I'm not at all familiar with that, but if the same library works in one application and not in another, perhaps its not the library.

Well, but if the previous version works, and there was no sonme bump (was there?).... than it rather looks like the bug might be in the lib, doesn't it?

Oh, and btw. GIMP must have the same "bug" as geeqie ;-) ... or - more likely - the lib is still broken.

All I know is viewnior and gpicview Debian packages can view .heic, but GM can't. https://bugs.debian.org/1053692

Can you check if heif-convert works? Does imagemagick convert work?

While deferring to your expertise, clearly something is different, and understanding where the difference is might be more useful analysis than "the lib is still broken".

Do the viewnior and gpicview Debian packages depend on libheif? Libheif is not the only way to decode HEIC. Does libheif on Debian depend on the packages it requires to read HEIC?

It would be useful if someone could post the trace output from GraphicsMagick when it fails to read HEIC. For example:

% gm convert -debug coder,exception C001.heic info:-
11:52:31 0:0.011821  0.010u 566896 constitute.c/unknown/1676/Coder:
  Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0
11:52:31 0:0.013892  0.010u 566896 heif.c/unknown/548/Coder:
  Geometry: 1280x720
11:52:31 0:0.013917  0.010u 566896 heif.c/unknown/550/Coder:
  Matte: False
11:52:32 0:0.150510  0.150u 566896 heif.c/unknown/652/Coder:
  heif_image_get_bits_per_pixel: bits_per_pixel=24
11:52:32 0:0.150541  0.150u 566896 heif.c/unknown/667/Coder:
  heif_image_get_plane_readonly: bytes-per-line=3840
11:52:32 0:0.157627  0.150u 566896 constitute.c/unknown/1689/Coder:
  Returned from "HEIC" decoder: frames=1 cache=present monochrome=False grayscale=False class=DirectClass colorspace=RGB
11:52:32 0:0.157924  0.150u 566896 constitute.c/unknown/2310/Coder:
  Invoking "INFO" encoder (Image descriptive information and statistics): cache=present adjoin=True type=Undefined monochrome=False
grayscale=False class=DirectClass colorspace=RGB
C001.heic HEIC 1280x720+0+0 DirectClass 8-bit 0.140u 0m:0.146082s (6.0Mi pixels/s)
11:52:32 0:0.157972  0.150u 566896 constitute.c/unknown/2325/Coder:
  Returned from "INFO" encoder, Succeeded

also:

 gm convert -list formats |fgrep -i heif
     AVIF P  r--  HEIF Image Format (heif v12.0.0)
     HEIC P  r--  HEIF Image Format (heif v12.0.0)
     HEIF P  r--  HEIF Image Format (heif v12.0.0)

but as far as I am aware, libheif does not provide a means to know what codecs it supports, and so codec support listed by GM is purely speculative.

Can you check if heif-convert works?

with 1.16.2 + the patch:

$ heif-convert 20230915_131854.heic ~/test.jpg
File contains 1 image
Written to /home/calestyo/test.jpg

Does imagemagick convert work?

with 1.16.2 + the patch:

$ convert 20230915_131854.heic ~/test.jpg
convert-im6.q16: no images defined `/home/calestyo/test.jpg' @ error/convert.c/ConvertImageCommand/3229.

after downgrading to 1.15.1:

$ convert 20230915_131854.heic ~/test.jpg
$ echo $?
0

It would be useful if someone could post the trace output from GraphicsMagick when it fails to read HEIC. For example:

with 1.16.2 + the patch:

$ gm convert -debug coder,exception 20230915_131854.heic info:-
23:57:22 0:0.000183  0.000u 537679 constitute.c/ReadImage/1676/Coder:
  Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0
23:57:22 0:0.003301  0.000u 537679 heif.c/ReadHEIFImage/571/Coder:
  Geometry: 4000x3000
23:57:22 0:0.003309  0.000u 537679 heif.c/ReadHEIFImage/573/Coder:
  Matte: False
23:57:22 0:0.003312  0.000u 537679 heif.c/ReadMetadata/191/Coder:
  Profile "Exif" with content type "" and size 876 bytes
23:57:22 0:0.003668  0.000u 537679 heif.c/ReadHEIFImage/650/Coder:
  heif_decode_image() reports error "Unsupported feature: Unsupported codec"
23:57:22 0:0.003961  0.000u 537679 heif.c/ReadHEIFImage/653/CorruptImage:
  An error has occurred reading from file (20230915_131854.heic)
23:57:22 0:0.003972  0.000u 537679 constitute.c/ReadImage/1702/Coder:
  Returned from "HEIC" decoder, returned image is NULL!
gm convert: An error has occurred reading from file (20230915_131854.heic).
$ gm convert -list formats |fgrep -i heif
     AVIF P  r--  HEIF Image Format (heif v16.2.0)
     HEIC P  r--  HEIF Image Format (heif v16.2.0)
     HEIF P  r--  HEIF Image Format (heif v16.2.0)

with 1.15.1:

$ gm convert -debug coder,exception 20230915_131854.heic info:-
23:56:14 0:0.000385  0.000u 536436 constitute.c/ReadImage/1676/Coder:
  Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0
23:56:14 0:0.003433  0.010u 536436 heif.c/ReadHEIFImage/571/Coder:
  Geometry: 4000x3000
23:56:14 0:0.003442  0.010u 536436 heif.c/ReadHEIFImage/573/Coder:
  Matte: False
23:56:14 0:0.003445  0.010u 536436 heif.c/ReadMetadata/191/Coder:
  Profile "Exif" with content type "" and size 876 bytes
23:56:14 0:0.220462  0.700u 536436 heif.c/ReadHEIFImage/679/Coder:
  heif_image_get_bits_per_pixel: bits_per_pixel=24
23:56:14 0:0.220478  0.700u 536436 heif.c/ReadHEIFImage/694/Coder:
  heif_image_get_plane_readonly: bytes-per-line=12000
23:56:14 0:0.240747  0.720u 536436 constitute.c/ReadImage/1689/Coder:
  Returned from "HEIC" decoder: frames=1 cache=present monochrome=False grayscale=False class=DirectClass colorspace=RGB
23:56:14 0:0.240808  0.720u 536436 constitute.c/WriteImage/2310/Coder:
  Invoking "INFO" encoder (Image descriptive information and statistics): cache=present adjoin=True type=Undefined monochrome=False grayscale=False class=DirectClass colorspace=RGB
20230915_131854.heic HEIC 4000x3000+0+0 DirectClass 8-bit 0.720u 0m:0.240422s (47.6Mi pixels/s)
23:56:14 0:0.240824  0.720u 536436 constitute.c/WriteImage/2325/Coder:
  Returned from "INFO" encoder, Succeeded
$ gm convert -list formats |fgrep -i heif
     AVIF P  r--  HEIF Image Format (heif v15.1.0)
     HEIC P  r--  HEIF Image Format (heif v15.1.0)
     HEIF P  r--  HEIF Image Format (heif v15.1.0)

Do the viewnior and gpicview Debian packages depend on libheif?

For gpicview I don't see a direct dependency:

  --\ Depends (7)
    --- libc6 (>= 2.34)
    --- libcairo2 (>= 1.10.0)
    --- libgdk-pixbuf-2.0-0 (>= 2.22.0)                                                                                                                                                       
    --- libglib2.0-0 (>= 2.38.0)
    --- libgtk-3-0 (>= 3.0.0)
    --- libjpeg62-turbo (>= 1.3.1)
    --- libx11-6
  --\ Recommends (1)
    --- xdg-utils

But I'd guess it might use libheif via heif-gdk-pixbuf.

Probably the same for viewnior:

  --\ Depends (8)
    --- libc6 (>= 2.34)
    --- libcairo2 (>= 1.2.4)
    --- libexiv2-27 (>= 0.27.2)                                                                                                                                                               
    --- libgcc-s1 (>= 3.0)
    --- libgdk-pixbuf-2.0-0 (>= 2.22.0)
    --- libglib2.0-0 (>= 2.38.0)
    --- libgtk-3-0 (>= 3.0.0)
    --- libstdc++6 (>= 13.1)

Oh, I shall add, that eog doesn’t seem to directly/indirectly depend on libheif1 either (but for that I'm sure that needs heif-gdk-pixbuf to display them), while in contrast geeqie, gimp, libgraphicsmagick-q16-3 and libmagickcore-6.q16-6 all directly depend on libheif1.

A quick scan through those repos shows that the ones that fail do not init the plugins, while heif-gdk-pixbuf does (naturally, since it's part of libheif itself). So the basic impression that #914 was not a sufficient fix appears correct.

On Sun, 8 Oct 2023, Emily Bowman wrote:

A quick scan through those repos shows that the ones that fail do not init the plugins, while heif-gdk-pixbuf does (naturally, since it's part of libheif itself).

By this, do you mean call heif_init() and heif_deinit()?

The documentation does not say if these are thread safe. I hope so!

Bob

I just checked and there is a mutex in the heif_init()/heif_deinit() implementation. It is likely that there is some cost to the first real init so for purposes of GraphicsMagick, I would only do such a thing if/when heif is actually used.

I put changes into GraphicsMagick Mercurial which should cause heif_init()/heif_deinit() to be used if available, but none of my libheif installs have these functions.

I had a deeper look and indeed, depending on what libheif function the client application is calling, it may start using it without heif_init() being implicitly called. I have fixed this in the change above. Please check whether it works for you with this patch. I tried with geeqie and it works now. No change in the client applications is needed (but it's never a mistake to call heif_init() explicitly).

Great, thanks! Do you have an ETA for a new release, or should I look into backporting the changes for the Debian packaging?

@fancycode We should make a new release soon. There are so many changes that a new release is well worth it.

https://github.com/strukturag/libheif/commit/c1a563fb46848d5228ba2d2359133a7097c9a499

eog still works, gimp still fails (Opening '20230830_143158.heic' failed: Unknown file type)... geeqie now displays the file in the main view, but displaying thumbnails still fails, though this might be some caching issue (when I copied the HEIF file to a new location, it worked). Also geeqie displays:

warning: heif reader error: Color profile does not exist: Unspecified

@calestyo Concerning gimp, I guess that this is because your gimp installation has been compiled without HEIF support or the gimp plugin is missing. The error Unknown file type is generated before libheif comes into play, as far as I know.

The geeqie error (probably warning) seems to come from an input image without embedded color profile.

Thus, in my view, this can be closed.

@farindk

Concerning gimp, I guess that this is because your gimp installation has been compiled without HEIF support or the gimp plugin is missing.

Uhm... no?!

As I've said several times previously (e.g. https://github.com/strukturag/libheif/issues/974#issuecomment-1752173597) gimp is also affected by this bug.

And obviously, it works again in gimp, when downgrading the to 1.15.1.

Please re-open.

Right, there was another code path. Gimp works again with the above change.

@farindk, It works now in gimp.

But something may still/newly be fishy in geeqie:

When I copy a heif file in a fresh dir (i.e. no thumbnail caching or so done yet) and start geeqie there, it fails to display the first heif image, again with a:

$  geeqie .
warning: heif reader error: Unsupported feature: Unsupported codec

warning: heif reader error: Color profile does not exist: Unspecified

If I then move down in the image list to another one, it starts to work, also when moving back to the original image.

Again, this doesn't happen on 1.15.1, though the colour profile warning happens there, too.

Any ideas?

I cannot reproduce this behavior with geeqie. I tried with the current 'master' version of geeqie and the v1.7.2 from Ubuntu 22.04: new directory with heic images, start geeqie inside that directory and it immediately shows the first image (even without that color-profile warning).

However, I noticed that geeqie does not show 10bit images correctly and crashes shortly afterwards.

Hmm strange… Debian has version 2.1.

Yes, the master branch from geeqie I checked out is also v2.1.

 ./geeqie --version
Geeqie 2.1+git20231007-aedccfcb GTK3

I guess mine’s really the true 2.1:

$ geeqie --version
Geeqie 2.1 GTK3

which I think was some 3 months old. So could be that some of the commits fixed something.
OTOH, a quick glance revealed none that would reference "heif".

Are you sure that there's no other possible path, where plugin loading might still be missing?

I just tried again, and in fact I see the same behaviour (failure on the first displayed file, but only when in a new directory) even without c5207b59ceb78d38917504553ba13568968d351f (but still with c1a563fb46848d5228ba2d2359133a7097c9a499). All a bit odd. As if loading plugins would happen only at the 2nd try.

You could add a printf() at the beginning of heif_init() in file init.cc like here:

struct heif_error heif_init(struct heif_init_params*)
{
  printf("called heif_init\n");

and check whether it is called when viewing the first image or only at the second image.

I have another idea. Maybe geeqie is calling libheif in parallel for all images and there is a race condition (second thread thinks it's already initialized while first thread is still in the initialization code).

Could you please check whether this change in init.cc helps:

void load_plugins_if_not_initialized_yet()
{
  std::lock_guard<std::recursive_mutex> lock(heif_init_mutex());

  if (heif_library_initialization_count == 0) {
    heif_init(nullptr);
  }
}

and check whether it is called when viewing the first image or only at the second image.

It is already printed on the first image

Could you please check whether this change in init.cc helps:

That fixes it. :-D (and it still works in gimp and eog)

If you'd say that's a misuse by geeqie, rather than some incompatible change in the library, I'd be also fine to just report that particular point as a bug against geeqie.

Oh and with "that" I meant adding the single.

   std::lock_guard<std::recursive_mutex> lock(heif_init_mutex());

I haven't checked b04bfc09776895a8cd5dc1ee02d529edb48e620e.

Nice. Good that we found that. It would be nice if you could test https://github.com/strukturag/libheif/commit/b04bfc09776895a8cd5dc1ee02d529edb48e620e too since I cannot reproduce the issue here. The commit should also fix it without requiring the mutex lock.

Just checked it, and seems to work in all cases. :-)

Thanks!

Great. Thanks for your help.

Thanks for fixing! :-)

Any estimate on when we'll see all this in a new release?

In the coming days, I believe.

warning: heif reader error: Color profile does not exist: Unspecified

@farindk This is such a common problem with heif writers, do you think it'd be possible to make this more of an INFO or DEBUG level warning, except in debug builds? (In which case maybe warnings should be errors.) I don't think their general "Who knows, screw it" attitude, much like the many malignments of JPEG standards, is going away anytime soon. They're already satisfied with whatever random default.

@silverbacknet Right. I think the warning is coming from the gdk-pixbuf loader. Since the ICC profile is completely optional, I don't think this warning should be there at all. I have simply removed it.

I think the warning is coming from the gdk-pixbuf loader. Since the ICC profile is completely optional, I don't think this warning should be there at all. I have simply removed it.

As I mentioned in the commit, this is potentially still useful info. Agreed a warning might not be warranted, but is there maybe some other logging mechanism to use?

@kmilos Isn't it possible to simply check the returned image if it has an ICC profile? As it is completely optional, I don't see why this should be logged. I mean, we also don't log anything if the image has no Exif data or if there is no alpha channel.

It's just a convenience to help with analyzing numerous bug reports I've seen in 3rd party apps of the kind "my heif/AVIF colours are completely wrong". Not all apps can do colour management in full - e.g. you have files w/ nclx but no ICC...

Not exactly the same as ignoring Exif, as the impact on output is potentially more severe (HEIF/AVIF is more frequently used w/ wide gamut and HDR; w/ JPEG/PNG/WebP you'll be ok falling back to sRGB 99% of the time without any feedback).

Still, it is indeed optional, and up to you (the libavif pixbuf loader just silently ignores it as well, and so does the webp-pixbuf-loader). I was just wondering if there was something convenient to readily take advantage of, while still keeping the verbosity down when not absolutely necessary...

(Speaking about warnings, boy it sure took a lot of digging to find out that the bug originated here. I started with why doesn't emacs show h e i c. Then I got to GM which just gives a error message, then finally got here. Okay never mind.)

guys, is heif-convert works but convert doesn't in Ubuntu 23.10

UPDATE I created a new issue, https://github.com/strukturag/libheif/issues/1315

strace -o temp/convert_trace.log convert /home/gigi/NextCloud/Documents/Accomodations/IMG_1626.HEIC /home/gigi/temp/IMG_1626.jpg
convert-im6.q16: no images defined `/home/gigi/temp/IMG_1626.jpg' @ error/convert.c/ConvertImageCommand/3229.

convert_trace.log

gm convert -debug coder,exception /home/gigi/NextCloud/Documents/Accomodations/IMG_1626.HEIC info:-
19:57:31 0:0.001214  0.000u 1583625 constitute.c/ReadImage/1676/Coder:
  Invoking "HEIC" decoder (HEIF Image Format) subimage=0 subrange=0
19:57:31 0:0.003685  0.000u 1583625 heif.c/ReadHEIFImage/571/Coder:
  Geometry: 3024x4032
19:57:31 0:0.003699  0.000u 1583625 heif.c/ReadHEIFImage/573/Coder:
  Matte: False
19:57:31 0:0.003710  0.000u 1583625 heif.c/ReadMetadata/191/Coder:
  Profile "Exif" with content type "" and size 2778 bytes
19:57:31 0:0.003724  0.000u 1583625 heif.c/ReadColorProfile/328/Coder:
  Found color profile of type "prof")
19:57:31 0:0.003730  0.000u 1583625 heif.c/ReadColorProfile/342/Coder:
  Reading ICC profile with size 536 bytes
19:57:31 0:0.004190  0.000u 1583625 heif.c/ReadHEIFImage/650/Coder:
  heif_decode_image() reports error "Unsupported feature: Unsupported codec"
19:57:31 0:0.004440  0.000u 1583625 heif.c/ReadHEIFImage/653/CorruptImage:
  An error has occurred reading from file (/home/gigi/NextCloud/Documents/Accomodations/IMG_1626.HEIC)
19:57:31 0:0.004461  0.000u 1583625 constitute.c/ReadImage/1702/Coder:
  Returned from "HEIC" decoder, returned image is NULL!
gm convert: An error has occurred reading from file (/home/gigi/NextCloud/Documents/Accomodations/IMG_1626.HEIC).

gm convert -list formats |fgrep -i heif
     AVIF P  r--  HEIF Image Format (heif v16.2.0)
     HEIC P  r--  HEIF Image Format (heif v16.2.0)
     HEIF P  r--  HEIF Image Format (heif v16.2.0)

ldd /usr/bin/heif-convert
        linux-vdso.so.1 (0x00007fffc93e3000)
        libheif.so.1 => /lib/x86_64-linux-gnu/libheif.so.1 (0x00007cc02e957000)
        libjpeg.so.8 => /lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007cc02e8d4000)
        libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007cc02e89c000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007cc02e600000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007cc02e878000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007cc02e200000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007cc02e5e1000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007cc02e4f6000)
        /lib64/ld-linux-x86-64.so.2 (0x00007cc02ea21000)

$ldd $(which convert)
        linux-vdso.so.1 (0x00007ffc39e8b000)
        libMagickCore-6.Q16.so.6 => /lib/x86_64-linux-gnu/libMagickCore-6.Q16.so.6 (0x000077efb6000000)
        libMagickWand-6.Q16.so.6 => /lib/x86_64-linux-gnu/libMagickWand-6.Q16.so.6 (0x000077efb5ed7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x000077efb5c00000)
        liblcms2.so.2 => /lib/x86_64-linux-gnu/liblcms2.so.2 (0x000077efb638c000)
        liblqr-1.so.0 => /lib/x86_64-linux-gnu/liblqr-1.so.0 (0x000077efb5800000)
        libfftw3.so.3 => /lib/x86_64-linux-gnu/libfftw3.so.3 (0x000077efb5400000)
        libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x000077efb5a11000)
        libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x000077efb633c000)
        libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x000077efb5734000)
        libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x000077efb6327000)
        libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x000077efb52c2000)
        libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x000077efb6312000)
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x000077efb62f3000)
        libltdl.so.7 => /lib/x86_64-linux-gnu/libltdl.so.7 (0x000077efb62e8000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x000077efb5649000)
        libgomp.so.1 => /lib/x86_64-linux-gnu/libgomp.so.1 (0x000077efb5e84000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x000077efb5e60000)
        /lib64/ld-linux-x86-64.so.2 (0x000077efb6419000)
        libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x000077efb517b000)
        libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 (0x000077efb4e00000)
        liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x000077efb5e2e000)
        libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x000077efb561e000)
        libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x000077efb5143000)
        libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x000077efb62d7000)
        libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x000077efb5119000)
        libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x000077efb507e000)
        libicudata.so.72 => /lib/x86_64-linux-gnu/libicudata.so.72 (0x000077efb3000000)
        libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x000077efb2c00000)
        libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x000077efb505b000)
        libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x000077efb62cf000)
        libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x000077efb5e26000)
        libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x000077efb5e11000)
        libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x000077efb504c000)

strukturag / libheif

displaying images still fails since version > 1.15.1 #974