libheif icon indicating copy to clipboard operation
libheif copied to clipboard

libheif chokes when opening Sony .hif files

Open speculatrix opened this issue 1 year ago • 2 comments
trafficstars

The problem

Trying to open a .HIF file causes Shotwell to run high CPU levels, and this has been traced to libheif.

It takes much longer to open the image compared to a JPG, and consumes up to four of my eight CPU cores. When using Shotwell, it's unresponsive, e.g. the left/right buttons to switch images take a long time to register, or pressing "crop" can take a few seconds to come up. After a while CPU usage drops, but, switching to another picture using left/right cursor causes CPU usage to jump up again.

Screenshot from 2024-10-28 11-41-42

The expected behaviour

When the folder is viewed, and the image is opened, it should be opened quite quickly, well under a second, not multiple seconds, and the program used to view the image should not become unresponsive.

Back story

I discovered this when trying to open image files, taken with my new Sony A3700, Shotwell 0.32.9 on an x86-64 laptop running Fedora 40.

I originally opened a bug report on Shotwell: https://gitlab.gnome.org/GNOME/shotwell/-/issues/5133#note_2260407 but Jens Georg traced it to libheif. For me, Eye Of Mate seems less affected by the problem.

Steps to reproduce the issue

DSC00634.zip

  • unpack the attached ZIP file to get the .HIF file
  • create a folder with some image files and put the attached HIF file there
  • open the image with shotwell
  • observe the excessive CPU usage

I do not see this happen when using Eye Of Mate as a viewer, but Jens Georg did

Copyright Licensing

I hold the copyright in the image, but I grant the libheif developers full non-commercial use of the image for testing, demos etc, and to keep the image for regression testing in future.

speculatrix avatar Oct 30 '24 11:10 speculatrix

here's Jens Georg's flame graph libheif-flame-graph-by-jens-georg

speculatrix avatar Oct 30 '24 11:10 speculatrix

HEIC is a much more complex format than JPEG. Thus it is clear that it is also much more computationally intensive to decode. That is not a bug.

That being said, the current master version and upcoming v1.19.0 is more efficient in decoding because it can skip internal color-space conversions if they are not required.

In order to make best use of this and get the fastest decoding speeds, heif_decode_image() should be called with heif_colorspace_undefined and heif_chroma_undefined such that libheif may decide which output format is the most efficient.

farindk avatar Oct 30 '24 18:10 farindk