Any chance of supporting HEIF?

[Algae666]

This may be the new hotness very soon

[lovell]

Nokia provide a reference implementation for the HEIF container format but I suspect it's the patent-encumbered HEVC codec it can contain that might be of more interest.

In terms of "hotness", the AV1 codec from the Alliance for Open Media, a group of tech companies that don't have HEVC-related patents, will probably become more widespread. (From libvips' point of view I guess this would have to involve exporting an image as a single frame "video".)

[jcupitt]

I agree, it's hard to see a patented codec getting much use. There's a free implementation in ffmpeg:

https://trac.ffmpeg.org/wiki/Encode/H.265

But there will be a range of potential legal issues using it in various parts of the world.

[Algae666]

Hrm, hadn't thought of the legal issues, was just thinking technically. Looking into that ffmpeg implementation, though... may be useful.

[jcupitt]

There's a free loader here which would be easy to adapt:

https://github.com/monostream/tifig

Though as noted it would need to be an optional feature.

[lovell]

It looks like https://github.com/monostream/tifig/tree/master/lib uses the same Nokia reference implementation under the hood. The way patents are discussed in its licence leads me to suspect it is incompatible with the LGPL :(

Has GPAC been considered? It is LGPL, supports HEIF and libgpac-dev is available via Debian/Ubuntu/etc. package managers.

https://github.com/gpac/gpac
http://download.tsi.telecom-paristech.fr/gpac/doc/libgpac/

[jcupitt]

My impression was that the Nokia library just handled the container format and that the patented codec stuff was all in libav (ffmpeg). I'm very unsure though.

@monostefan, do you have an opinion on this issue?

GPAC sounds interesting, I'll have a look.

[streinhard]

You're right @lovell, tifig uses the Nokia library under the hood. We are building this tool because we need something to generate thumbnails from HEIF images in the cloud storage service we're working on and it seems to us that there really isn't any such (open source) tool around yet. At least nothing that runs in a halfway decent amount of time and is able to leverage the 320x240 thumbnails stored in every HEIF image created on a iOS 11 device. As far as I know, not even gpac does that.

I'm not really and expert on the HEIF licensing issue and I'm certainly not a lawyer. However, what I can tell you is that the Nokia library doesn't have any HEVC encoder or decoder built in. All it does is extracting encoded streams from or pack them into a HEIF container. You can use any free implementation for that such as ffmpeg/libav or libde265.

The remaining question is what the license of Nokias library want's to tell us. As far as I understand it, there are three important points:

• Don't even think about suing us or we'll sue you and will prohibit you from using HEIF forever
• Be aware of the fact that HEVC codec is heavily patented and we don't own any of those patents
• Other than that, this thing is MIT licensed, so go and have fun, yaaaay!

[lovell]

Thanks @monostefan, it'd be worth you getting a lawyer to check the nokiatech/heif licence if this is going to be used in a commercial product due to the explicit "non-commercial purposes..." clause.

It looks like ImageMagick might be going with libde265 plus custom demux logic - see ImageMagick/ImageMagick#507

[jcupitt]

That IM issue is interesting, thanks @lovell!

The mux/demux stuff seems rather simple, fortunately. Nokia's non-commercial clause is extremely irritating. libde265 looks great.

[streinhard]

Oh and yeah, as @lovell pointed out, there's that paragraph in @nokiatech's license that restricts its use to non-commercial applications, defined as evaluation, testing and academic research exclusively. Basically this makes the whole thing unusable as others have pointed out.

How wonderful would it be if Nokia sues us for using a library they created to to support an image format they invented ;). I doubt that this will ever happen though. Nevertheless, I will consult with our legal team...

On the other hand, it shouldn't be too hard to write or use a Base Media File Format parser to get the necessary bytes out of a HEIC file (a HEIF image using HEVC encoding). The next challenge then would be to support the entire standard. HEIF not only supports other encodings like AVC or JPEG, there's also a plethora of image types, like single images, image collections (burst shots), animated image sequences, images derived from auxiliary images, grid and single stream based images and many more.

[lovell]

As predicted there's a draft AV1-based image format called AVIF being proposed by Netflix - see https://github.com/AOMediaCodec/av1-avif - but it still requires a HEIF container.

The relatively new https://github.com/strukturag/libheif has a straightforward API, is LGPL, is available for Debian, relies on the same libde265 as ImageMagick and is plugin-based for possible future AVIF support.

[jrobber]

How is this not a higher priority? HEIC is the default on iOS 11 and on. Meaning you have millions of devices that can't upload to web-servers. Sharp and libvips are awesome but it seems crazy that libvips still doesn't support the new iOS default.

[lovell]

@jrobber I'm sure a pull request to add a libheif-based loader and saver to libvips would be most welcome. Happy to help review if you're able.

[jrobber]

@lovell I've never done this kind of code before. If you're able to point me in a starting direction and give me some high level steps I might take a crack at it. But at the same time. I assume that if it was that easy someone else would have done it.

[jcupitt]

I would start from one of the existing loaders and modify it. For example, the NIfTI loader is here:

https://github.com/libvips/libvips/blob/master/libvips/foreign/niftiload.c

It's not especially easy, unfortunately :( You need to know about gobject, libvips, libheif and of course HEIC itself.

[jrobber]

@jcupitt Thanks! Unfortunately C is my kryptonite. I'm happy to contribute financially to someone who wants to do this, but in the mean time I'm going to have to put a 2nd image processor in and move forward with my project.

[jcupitt]

I had a quick hack and added vips_heifload(), using libheif:

https://github.com/libvips/libvips/tree/add-heifload

It works on simple RGB images, but does not have any options, and does not support any metadata, other than the very basic width / height / etc.

I'll try to get it working on the Nokia test images, and add metadata support.

[jcupitt]

It now loads at least something from everything in the nokia test set, and supports exif metadata.

Does anyone have a test image with XMP or IPTC metadata?

It doesn't look like libheif supports gif-style animated images yet, but it should support images with alpha, and image collections. I'm unsure about tiled image support.

[rayshan]

@jcupitt here's an image taken with the Lightroom app on iPhone XS: https://www.dropbox.com/s/oe7hxfuzzaqbj3l/photo%20for%20jcupitt%20on%20GitHub.HEIC?dl=0

This is what Finder shows:

exiv2 doesn't report any metadata.

[mceachen]

@rayshan thanks for sharing. See Exiv2/exiv2#318. If you need metadata via node, ExifTool-vendored pulls out 125 tags from your file, fwiw (because ExifTool rocks!)

[jcupitt]

Oh nice! Thanks @rayshan.

I now see:

john@kiwi:~/pics/heic$ vipsheader -a demo.heic 
n_top = 1
  id[0] = 49
    width = 3024
    height = 4032
    depth = 0
    n_metadata = 1
    colour profile type = 1886547814
metadata type = Exif, length = 2124
profile data, length = 548
demo.heic: 3024x4032 uchar, 3 bands, srgb, heifload
width: 3024
height: 4032
bands: 3
format: uchar
coding: none
interpretation: srgb
xoffset: 0
yoffset: 0
xres: 2.83465
yres: 2.83465
filename: demo.heic
vips-loader: heifload
exif-data: 2120 bytes of binary data
resolution-unit: in
exif-ifd0-Make: Apple (Apple, ASCII, 6 components, 6 bytes)
exif-ifd0-Model: iPhone XS (iPhone XS, ASCII, 10 components, 10 bytes)
exif-ifd0-Orientation: 6 (Right-top, Short, 1 components, 2 bytes)
exif-ifd0-XResolution: 72/1 (72, Rational, 1 components, 8 bytes)
exif-ifd0-YResolution: 72/1 (72, Rational, 1 components, 8 bytes)
exif-ifd0-ResolutionUnit: 2 (Inch, Short, 1 components, 2 bytes)
exif-ifd0-Software: 12.1 (12.1, ASCII, 5 components, 5 bytes)
exif-ifd0-DateTime: 2018:11:22 10:12:55 (2018:11:22 10:12:55, ASCII, 20 components, 20 bytes)
exif-ifd0-YCbCrPositioning: 1 (Centred, Short, 1 components, 2 bytes)
exif-ifd2-ExposureTime: 1/999 (1/999 sec., Rational, 1 components, 8 bytes)
exif-ifd2-FNumber: 12/5 (f/2.4, Rational, 1 components, 8 bytes)
exif-ifd2-ExposureProgram: 2 (Normal programme, Short, 1 components, 2 bytes)
exif-ifd2-ISOSpeedRatings: 16 (16, Short, 1 components, 2 bytes)
exif-ifd2-ExifVersion: Exif Version 2.21 (Exif Version 2.21, Undefined, 4 components, 4 bytes)
exif-ifd2-DateTimeOriginal: 2018:11:22 10:12:55 (2018:11:22 10:12:55, ASCII, 20 components, 20 bytes)
exif-ifd2-DateTimeDigitized: 2018:11:22 10:12:55 (2018:11:22 10:12:55, ASCII, 20 components, 20 bytes)
exif-ifd2-ComponentsConfiguration: Y Cb Cr - (Y Cb Cr -, Undefined, 4 components, 4 bytes)
exif-ifd2-ShutterSpeedValue: 12575/1262 (9.96 EV (1/999 sec.), SRational, 1 components, 8 bytes)
exif-ifd2-ApertureValue: 131348/51997 (2.53 EV (f/2.4), Rational, 1 components, 8 bytes)
exif-ifd2-BrightnessValue: 20030/1819 (11.01 EV (7073.36 cd/m^2), SRational, 1 components, 8 bytes)
exif-ifd2-ExposureBiasValue: 0/1 (0.00 EV, SRational, 1 components, 8 bytes)
exif-ifd2-MeteringMode: 3 (Spot, Short, 1 components, 2 bytes)
exif-ifd2-Flash: 16 (Flash did not fire, compulsory flash mode, Short, 1 components, 2 bytes)
exif-ifd2-FocalLength: 6/1 (6.0 mm, Rational, 1 components, 8 bytes)
exif-ifd2-SubjectArea: 2940 2255 751 753 (Within rectangle (width 751, height 753) around (x,y) = (2940,2255), Short, 4 components, 8 bytes)
exif-ifd2-MakerNote: 1028 bytes undefined data (1028 bytes undefined data, Undefined, 1028 components, 1028 bytes)
exif-ifd2-SubSecTimeOriginal: 620 (620, ASCII, 4 components, 4 bytes)
exif-ifd2-SubSecTimeDigitized: 620 (620, ASCII, 4 components, 4 bytes)
exif-ifd2-FlashPixVersion: FlashPix Version 1.0 (FlashPix Version 1.0, Undefined, 4 components, 4 bytes)
exif-ifd2-ColorSpace: 65535 (Internal error (unknown value 65535), Short, 1 components, 2 bytes)
exif-ifd2-PixelXDimension: 4032 (4032, Long, 1 components, 4 bytes)
exif-ifd2-PixelYDimension: 3024 (3024, Long, 1 components, 4 bytes)
exif-ifd2-SensingMethod: 2 (One-chip colour area sensor, Short, 1 components, 2 bytes)
exif-ifd2-SceneType: Directly photographed (Directly photographed, Undefined, 1 components, 1 bytes)
exif-ifd2-ExposureMode: 0 (Auto exposure, Short, 1 components, 2 bytes)
exif-ifd2-WhiteBalance: 0 (Auto white balance, Short, 1 components, 2 bytes)
exif-ifd2-FocalLengthIn35mmFilm: 52 (52, Short, 1 components, 2 bytes)
exif-ifd2-SceneCaptureType: 0 (Standard, Short, 1 components, 2 bytes)
exif-ifd3-GPSLatitudeRef: N (N, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSLatitude: 24/1 11/1 3119/100 (24, 11, 31.19, Rational, 3 components, 24 bytes)
exif-ifd3-GPSLongitudeRef: E (E, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSLongitude: 121/1 39/1 4148/100 (121, 39, 41.48, Rational, 3 components, 24 bytes)
exif-ifd3-GPSAltitudeRef: Sea level (Sea level, Byte, 1 components, 1 bytes)
exif-ifd3-GPSAltitude: 182213/2794 (65.2158, Rational, 1 components, 8 bytes)
exif-ifd3-GPSTimeStamp: 2/1 12/1 5452/100 (02:12:54.52, Rational, 3 components, 24 bytes)
exif-ifd3-GPSSpeedRef: K (K, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSSpeed: 10357/253992 (0.040777, Rational, 1 components, 8 bytes)
exif-ifd3-GPSImgDirectionRef: M (M, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSImgDirection: 139325/2711 (51.3925, Rational, 1 components, 8 bytes)
exif-ifd3-GPSDestBearingRef: M (M, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSDestBearing: 139325/2711 (51.3925, Rational, 1 components, 8 bytes)
exif-ifd3-GPSDateStamp: 2018:11:22 (2018:11:22, ASCII, 11 components, 11 bytes)
orientation: 6
icc-profile-data: 548 bytes of binary data

[jcupitt]

It seems to handle the profile correctly too, I see:

$ vips icc_import demo.heic x2.jpg[strip]

To make:

[rayshan]

@mceachen thanks I'll keep that in mind.

@jcupitt happy to help.

[jcupitt]

I'll try to add multi-page read too.

An example with XMP metadata would be great, if anyone knows of one.

[rayshan]

The iOS Camera app also doesn't write anything to XMP. ExifTool only has read-only support for HEIF / HEIC currently so I couldn't copy the tags over.

I found this link on Google: https://winaero.com/blog/heif-heic-images-windows-10/. The samples in the post have XMP metadata: https://1drv.ms/u/s!AuKNsLlK8k5jih-WGHX1J0UnOffb

[jcupitt]

Oh, nice, I searched but failed to find an XMP example. I'll test that this weekend. Thanks!

[jcupitt]

Still to do:

• Add support for memory sources.
• Add heifsave.
• Add some tests.
• Add save to memory.
• Add primary image tagging on save.
• Add support for stored thumbnails.

The WONTFIX is probably:

• There's a mechanism in libheif to query and set extra encoder params, is this useful?
• Alpha is mysterious. None of the Nokia test images seem to use this feature. I imagine that for now this is probably not very useful, since heif is being used for camera output.
• No support for depth images. Recent iPhones (for example) will attach (I think) depth info from the front laser to images taken with the front camera. Probably unimportant for us.
• No support for mono (greyscale) images. We'd need a test case. Again, camera images won't ever use this feature.
• No support for grid (tiled) images. Again, we'd need a sample image.
• No support for animated sequences. git master libheif does not support these yet.
• No support for high bit depth images (> 8 bits per channel). Useful? No idea.

[jcupitt]

OK, I think it's pretty much done. Would anyone be able to try it out? Are there any obvious missing features?

The ignore_transformations flag on heifload should probably default to on (ie. transforms should only be applied if you set autorot). At the moment I think you can end up with double transforms, since the attached exif will also record the orientation.

[jcupitt]

I removed ignore_transformations and added autorotate instead, so it behaves like the other loaders.

I added a thumbnail option, meaning "load stored thumbnails rather than the main images", and the thumbnail operation uses it when it can.

Benchmarks! With no stored thumbnails, it's about 0.5s for a typical smartphone image:

$ time vipsthumbnail Example1.heic --vips-info
VIPS-INFO: 16:21:45.317: thumbnailing Example1.heic
VIPS-INFO: 16:21:45.320: selected loader is VipsForeignLoadHeifFile
VIPS-INFO: 16:21:45.320: input size is 4032 x 3024
VIPS-INFO: 16:21:45.325: pre-shrunk size is 4032 x 3024
VIPS-INFO: 16:21:45.325: converting to processing space srgb
VIPS-INFO: 16:21:45.325: shrinkv by 15
VIPS-INFO: 16:21:45.325: shrinkv sequential line cache
VIPS-INFO: 16:21:45.325: shrinkh by 15
VIPS-INFO: 16:21:45.325: residual reducev by 0.47619
VIPS-INFO: 16:21:45.325: reducev: 14 point mask
VIPS-INFO: 16:21:45.326: reducev: using vector path
VIPS-INFO: 16:21:45.326: reducev sequential line cache
VIPS-INFO: 16:21:45.326: residual reduceh by 0.47619
VIPS-INFO: 16:21:45.326: reduceh: 14 point mask
VIPS-INFO: 16:21:45.326: thumbnailing Example1.heic as ./tn_Example1.jpg

real	0m0.488s
user	0m0.686s
sys	0m0.046s

It's obviously quick if there are thumbnails available:

$ time vipsthumbnail old_bridge_1440x960.heic --vips-info
VIPS-INFO: 16:21:53.751: thumbnailing old_bridge_1440x960.heic
VIPS-INFO: 16:21:53.752: selected loader is VipsForeignLoadHeifFile
VIPS-INFO: 16:21:53.752: input size is 1440 x 960
VIPS-INFO: 16:21:53.753: pre-shrunk size is 240 x 160
VIPS-INFO: 16:21:53.753: converting to processing space srgb
VIPS-INFO: 16:21:53.753: residual reducev by 0.533333
VIPS-INFO: 16:21:53.753: reducev: 12 point mask
VIPS-INFO: 16:21:53.754: reducev: using vector path
VIPS-INFO: 16:21:53.754: reducev sequential line cache
VIPS-INFO: 16:21:53.754: residual reduceh by 0.533333
VIPS-INFO: 16:21:53.754: reduceh: 12 point mask
VIPS-INFO: 16:21:53.754: thumbnailing old_bridge_1440x960.heic as ./tn_old_bridge_1440x960.jpg

real	0m0.045s
user	0m0.037s
sys	0m0.008s

[rayshan]

Would @lovell be the perfect tester? I'm a loyal sharp user :)

[lovell]

@jcupitt Amazing, thank you John, I'll try to take a look soon.

@rayshan Based on what John's demonstrated here I'd expect sharp to "just work" reading HEIC images when compiled against a version of libvips that supports libheif/libde265. Writing HEIC images would require a change to sharp to expose the setting of output options.

[jcupitt]

Docs, if anyone is curious:

https://github.com/libvips/libvips/blob/add-heifload/libvips/foreign/heifload.c#L810

https://github.com/libvips/libvips/blob/add-heifload/libvips/foreign/heifsave.c#L569

The reduction in filesize is impressive, and larger than I'd expected.

john@yingna ~/pics $ vips copy Gugg_coloured.jpg x.jpg[strip]
john@yingna ~/pics $ ls -l x.jpg
-rw-r--r-- 1 john john 131560 Feb  1 14:05 x.jpg
john@yingna ~/pics $ vips copy x.jpg y-10.heic[strip,Q=10]
john@yingna ~/pics $ vips copy x.jpg y-30.heic[strip,Q=30]
john@yingna ~/pics $ vips copy x.jpg y-50.heic[strip,Q=50]
john@yingna ~/pics $ ls -l y*
-rw-r--r-- 1 john john   7548 Feb  1 14:06 y-10.heic
-rw-r--r-- 1 john john  31362 Feb  1 14:06 y-30.heic
-rw-r--r-- 1 john john 105262 Feb  1 14:06 y-50.heic

First the original (131kb, Q75 jpg):

A Q10 heic, 7.5kb:

Q30 heic, 31kb:

Q50 heic, 105kb:

So Q50 gives about the same size as Q75 jpg. Q10 looks awful, but the size is just tiny. Q30 looks roughly same (to my terrible old eyes) as Q75 jpg, but is more than 4x smaller.

[jcupitt]

I forgot to say, those image are probably larger than shown, so you are seeing your browser downsize.

Open each one in a separate tab, make sure you are zoomed in, and try flipping between tabs.

[remicollet]

Just to confirm, libheif is NOT available in most Linux distro (probably because of patent issue)

[jcupitt]

I think (!?) there are no patent issues around libheif itself. It uses x265 and libde265 for encode / decode, and they are the things that infringe. Users in countries where software patents are a thing would need to make separate arrangements.

It's in Debian sid, for example, though not yet in Ubuntu.

https://packages.debian.org/sid/libheif-dev

I agree that including it in binaries we distribute would need thought. Users would need to be aware of the patent problems.

They are also GPL, of course, so the same restrictions that libpoppler faces would apply.

[remicollet]

It uses x265 and libde265 for encode / decode, and they are the things that infringe.

Same problem, as dependency are not available...

[lovell]

HEVC patent licensing is sadly a fragmented mess that could bring about its demise. Of the three(?!) patent pools, HEVC Advance is the most progressive and allows royalty-free software-only implementations such as libde265. It is likely that libde265 is impacted by patents from other pools (MPEG LA, Velos) and individual holders (Technicolor, Intel etc.) so I would seek legal advice before distributing binaries of libde265.

Ubuntu 18.04+ provides libheif and Ubuntu 16.04+ provides libde265; both are LGPL.

Allowing libvips to read and write the patent-free HEIF container via libheif provides the gateway to future royalty-free encoding formats such as AVIF.

[jcupitt]

Ah, I'm sure I saw a page saying de265 was GPL, but you're right, it's LGPL3, that's good.

Let's merge to master, it'll make testing simpler as we get ready for 8.8.

Any problems, please open a new issue. Thanks!

[leslie-wang]

Thanks for the great work!

If I want to convert HEIC to jpeg, is vips jpegsave ~/IMG_4479.HEIC /tmp/test.jpg right command? Seems like it got segment fault failure when I compile and run on MAC OS. Thumbnail generation also got core dump.

$ vipsthumbnail ~/IMG_4479.HEIC --vips-info
VIPS-INFO: 23:36:34.357: thumbnailing /Users/qiwa/IMG_4479.HEIC
VIPS-INFO: 23:36:34.374: selected loader is VipsForeignLoadHeifFile
VIPS-INFO: 23:36:34.374: input size is 3024 x 4032
VIPS-INFO: 23:36:34.401: pre-shrunk size is 240 x 320
VIPS-INFO: 23:36:34.401: converting to processing space srgb
VIPS-INFO: 23:36:34.401: residual reducev by 0.4
VIPS-INFO: 23:36:34.401: reducev: 16 point mask
VIPS-INFO: 23:36:34.403: reducev: using vector path
VIPS-INFO: 23:36:34.403: reducev sequential line cache
VIPS-INFO: 23:36:34.404: residual reduceh by 0.4
VIPS-INFO: 23:36:34.404: reduceh: 16 point mask
VIPS-INFO: 23:36:34.404: thumbnailing /Users/test/IMG_4479.HEIC as /Users/test/tn_IMG_4479.jpg
Segmentation fault: 11

vipsheader -a  ~/IMG_4479.HEIC 
/Users/test/IMG_4479.HEIC: 3024x4032 uchar, 3 bands, srgb, heifload
width: 3024
height: 4032
bands: 3
format: uchar
coding: none
interpretation: srgb
xoffset: 0
yoffset: 0
xres: 2.83465
yres: 2.83465
filename: /Users/test/IMG_4479.HEIC
vips-loader: heifload
heif-primary: 0
n-pages: 1
page-height: 4032
exif-data: 2096 bytes of binary data
resolution-unit: in
exif-ifd0-Make: Apple (Apple, ASCII, 6 components, 6 bytes)
exif-ifd0-Model: iPhone 7 Plus (iPhone 7 Plus, ASCII, 14 components, 14 bytes)
exif-ifd0-Orientation: 6 (Right-top, Short, 1 components, 2 bytes)
exif-ifd0-XResolution: 72/1 (72, Rational, 1 components, 8 bytes)
exif-ifd0-YResolution: 72/1 (72, Rational, 1 components, 8 bytes)
exif-ifd0-ResolutionUnit: 2 (Inch, Short, 1 components, 2 bytes)
exif-ifd0-Software: 11.0 (11.0, ASCII, 5 components, 5 bytes)
exif-ifd0-DateTime: 2017:09:13 06:27:17 (2017:09:13 06:27:17, ASCII, 20 components, 20 bytes)
exif-ifd0-YCbCrPositioning: 1 (Centered, Short, 1 components, 2 bytes)
exif-ifd2-ExposureTime: 1/20 (1/20 sec., Rational, 1 components, 8 bytes)
exif-ifd2-FNumber: 9/5 (f/1.8, Rational, 1 components, 8 bytes)
exif-ifd2-ExposureProgram: 2 (Normal program, Short, 1 components, 2 bytes)
exif-ifd2-ISOSpeedRatings: 40 (40, Short, 1 components, 2 bytes)
exif-ifd2-ExifVersion: Exif Version 2.21 (Exif Version 2.21, Undefined, 4 components, 4 bytes)
exif-ifd2-DateTimeOriginal: 2017:09:13 06:27:17 (2017:09:13 06:27:17, ASCII, 20 components, 20 bytes)
exif-ifd2-DateTimeDigitized: 2017:09:13 06:27:17 (2017:09:13 06:27:17, ASCII, 20 components, 20 bytes)
exif-ifd2-ComponentsConfiguration: Y Cb Cr - (Y Cb Cr -, Undefined, 4 components, 4 bytes)
exif-ifd2-ShutterSpeedValue: 3047/705 (4.32 EV (1/20 sec.), SRational, 1 components, 8 bytes)
exif-ifd2-ApertureValue: 2159/1273 (1.70 EV (f/1.8), Rational, 1 components, 8 bytes)
exif-ifd2-BrightnessValue: 15586/5471 (2.85 EV (24.68 cd/m^2), SRational, 1 components, 8 bytes)
exif-ifd2-ExposureBiasValue: 0/1 (0.00 EV, SRational, 1 components, 8 bytes)
exif-ifd2-MeteringMode: 5 (Pattern, Short, 1 components, 2 bytes)
exif-ifd2-Flash: 24 (Flash did not fire, auto mode, Short, 1 components, 2 bytes)
exif-ifd2-FocalLength: 399/100 (4.0 mm, Rational, 1 components, 8 bytes)
exif-ifd2-SubjectArea: 2015 1511 2217 1330 (Within rectangle (width 2217, height 1330) around (x,y) = (2015,1511), Short, 4 components, 8 bytes)
exif-ifd2-MakerNote: 994 bytes undefined data (994 bytes undefined data, Undefined, 994 components, 994 bytes)
exif-ifd2-SubSecTimeOriginal: 266 (266, ASCII, 4 components, 4 bytes)
exif-ifd2-SubSecTimeDigitized: 266 (266, ASCII, 4 components, 4 bytes)
exif-ifd2-FlashPixVersion: FlashPix Version 1.0 (FlashPix Version 1.0, Undefined, 4 components, 4 bytes)
exif-ifd2-ColorSpace: 65535 (Uncalibrated, Short, 1 components, 2 bytes)
exif-ifd2-PixelXDimension: 4032 (4032, Long, 1 components, 4 bytes)
exif-ifd2-PixelYDimension: 3024 (3024, Long, 1 components, 4 bytes)
exif-ifd2-SensingMethod: 2 (One-chip color area sensor, Short, 1 components, 2 bytes)
exif-ifd2-SceneType: Directly photographed (Directly photographed, Undefined, 1 components, 1 bytes)
exif-ifd2-ExposureMode: 0 (Auto exposure, Short, 1 components, 2 bytes)
exif-ifd2-WhiteBalance: 0 (Auto white balance, Short, 1 components, 2 bytes)
exif-ifd2-FocalLengthIn35mmFilm: 28 (28, Short, 1 components, 2 bytes)
exif-ifd2-SceneCaptureType: 0 (Standard, Short, 1 components, 2 bytes)
exif-ifd3-GPSLatitudeRef: S (S, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSLatitude: 23/1 32/1 2362/100 (23, 32, 23.62, Rational, 3 components, 24 bytes)
exif-ifd3-GPSLongitudeRef: W (W, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSLongitude: 46/1 39/1 2358/100 (46, 39, 23.58, Rational, 3 components, 24 bytes)
exif-ifd3-GPSAltitudeRef: Sea level (Sea level, Byte, 1 components, 1 bytes)
exif-ifd3-GPSAltitude: 69245/89 (778.03, Rational, 1 components, 8 bytes)
exif-ifd3-GPSTimeStamp: 9/1 27/1 1597/100 (09:27:15.97, Rational, 3 components, 24 bytes)
exif-ifd3-GPSSpeedRef: K (K, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSSpeed: 11/25 (0.44, Rational, 1 components, 8 bytes)
exif-ifd3-GPSImgDirectionRef: M (M, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSImgDirection: 69821/215 (324.749, Rational, 1 components, 8 bytes)
exif-ifd3-GPSDestBearingRef: M (M, ASCII, 2 components, 2 bytes)
exif-ifd3-GPSDestBearing: 69821/215 (324.749, Rational, 1 components, 8 bytes)
exif-ifd3-GPSDateStamp: 2017:09:13 (2017:09:13, ASCII, 11 components, 11 bytes)
orientation: 6
icc-profile-data: 548 bytes of binary data

[leslie-wang]

The test image is from https://trac.ffmpeg.org/attachment/ticket/6521/IMG_4479.HEIC.

[jcupitt]

Hi @leslie-wang, yes, I see a crash here too, it looks like libvips is asking for RGB, but libheif is handing over RGBA. I'll have a look.

[jcupitt]

I've opened a new issue #1247, let's move there.

[jcupitt]

In case anyone comes across this old issue, libvips now has full avif support via libheif and aom.