search

strukturag / libheif

libheif is an HEIF and AVIF file format decoder and encoder.
Other
1.7k stars 298 forks source link

Distortion in encoded .heic files #373

Open Luthien-in-edhil opened 3 years ago

Luthien-in-edhil commented 3 years ago

Hoping I'm not reporting something very obvious, but I couldn't find any other reference to the particular issue I have. I was trying to find a workflow that allows me to store scanned pictures in a higher bit depth than 8, but preferably with a less demanding space requirement than regular 16-bit TIFF or PNG files. Because Apple somehow disabled exporting 16-bit .heic images (the greyed-out 16-bit option in Preview.app), I eventually found libheif, as described here.

I'm having some problems, though. Here's what I found, hopefully it's of some use :) The pictures I scan are mostly old black&white photo negatives, and I first tested with greyscale 16-bit PNG files as input, but I also tried with RGB 16-bit (48 bit) RGB copies of the same images, and made both an odd-sized (1135 x 747) and an even-sized (1136 x 748) version of each.

I first tried with the -E option, like this:

> heif-enc -E -b 12 -q 90 <input file>

eventually I tried it without the -E option:

> heif-enc -E -b 12 -q 90 <input file>

Using libheif version: 1.9.1, x265 HEVC encoder (0.0) Mac OS 10.15.7

silverbacknet commented 3 years ago

What is the specific decoder? Preview? Would be worth testing heif-dec and ffmpeg as well.

Quite a few decoders have issues with odd sizes on newer formats, I don't have access to a 10.15 system myself to test though, but that sounds worse than usual.

Luthien-in-edhil commented 3 years ago

Thanks. I'll look into the decoder as soon as I'm off work. If it's any help, I wouldn't mind doing some testing either.

Luthien-in-edhil commented 3 years ago

tbh, I'm not sure I understand your question. I read over it this morning I think. The thing is, I wasn't trying to decode an image, but to encode it :)

The encoder I used was the default x265 HEVC encoder (0.0)

When I tested it yesterday I couldn't select any other encoders. Trying to list them gives:

heif-enc --list-encoders Encoders (first is default): - x265 = x265 HEVC encoder (0.0) heif-enc libheif version: 1.9.1 ----------------------------------------

I had libheif installed via homebrew, so today I built it from source to see if that would make a difference. I indeed noticed that the -E switch is now deprecated, and the results of yesterday's test are now different: the greyscale PNG files are still converted in a horizontally stretched, grainy image, but both odd and even-sized RGB ones are now converted in good .heic files. I also noticed that those distorted greyscale .heic files are more than double the size of the (correct) RBB ones, so there's something funky going on there.

Anyway, re. the different encoders: I first assumed that optional encoders or decoders should be available as external dependencies, but rav1e & aom seem to be included in the /libheif directory. Following the build instructions from the readme.md for osx did not result in them being listed with -list--encoders though, I still only see the one default x265 HEVC encoder (0.0) and trying to select another one ( -e 1 ) results in

When I tested it yesterday I couldn't select any other encoders. Trying to list them resulted in

heif-enc -e 1 -P Unknown encoder ID. Choose one from the list below.

I'll have a closer look at the config.log, maybe I need to change how the library is built.

silverbacknet commented 3 years ago

Right, you're encoding, but somewhere along the line you have to decode it to be able to see it again. If that's the default decoder built into Preview, it's good to know for that case, especially vs how other decoders behave on macOS, but if it's everything then maybe there's a Mac specific bug somewhere. Making available sample encoded files that made things fail will help too.

Luthien-in-edhil commented 3 years ago

Ah, I see. Thanks. Yes, I'll prepare some examples.

Luthien-in-edhil commented 3 years ago

Anyhow, yes, I did view them with the builtin preview decoder (and preview.app). I'll go check out some other viewers / decoders. I'll in any case try Gimp and Affinity Photo and let you know how they look there.

Here's some examples. I also uploaded the binaries I compiled yesterday.

I tested with an original colour image and an original greyscale one.

Re. the colour original: I created four versions of a 16-bit RGB image:

Since the dimensions don't seem to matter any longer, I skipped that now. These were all converted to .heic with:

heif-enc -b 12 -q 90 {image.png}

resulting in

The RGB versions both produced a good heic version (creating a 12-bit heic for the 16-bit png, and a 8-bit heic for the 8-bit png). The 8-bit greyscale png also works fine, but the 16 bit greyscale is horizontally distorted / stretched. I could now also see much clearer what is happening: if you look at slide-scan-res-grey16-8-DIST.heic it is clear that it cut in vertical 1-pixel wide lines, separated by a white 1-pixel line. It's also interesting that with this colour original I don't get the added noise, as with the greyscale original; I suppose that's because this is a scan of a colour slide that doesn't have the typical film grain of black & white negatives (or in any case not that evidently).

Re. the greyscale original:

I included those because for this file, the noise level in the one distorted .heic file ( joop-ciago-grey16-8-DIST.heic ) is so striking. In all other respects the results were the same as with the colour slide original.

I'll try to find out how to view the produced .heic files using another decoder

Luthien-in-edhil commented 3 years ago

Viewing the above-mentioned .heic files with Krita (4.4.1): Krita doesn't open any of the greyscale .heic files ("the file cannot be parsed). The 8-bit RGB ones are fine, but the 12-bit RGB ones have the same sort of horizontal interlacing / stretching as the 16-to-12bit turning as 8 bit greyscale one has when viewed using mac Preview.

Thinking about it, the increased noise in the greyscale 16-to-12-no-actually-8 bits one (in preview) makes some sense: I can imagine how mapping the lesser significant bits to more significant ones would have that effect. But I'm clueless whether that happens in preview or in the encoding process. For Krita it's somewhat different: in there the 16-to-12 RGB heic files are also distorted with the horizontal interlacing / stretching; and there is also something definitely wrong with how the values are assigned. The colour one looks almost psychedelic there - I will add a screenshot to the /images on that test repo.

I'll look for some other viewers or decoders yet, I'm curious what they do.

Luthien-in-edhil commented 3 years ago

Gimp: I tested that even though it uses the same lib-heif library as Krita and it behaves the same, indeed.

Luthien-in-edhil commented 3 years ago

ffmpeg: I installed a version with brew install ffmpeg --with-x265 but unfortunately, so far I can't decode .heic files with it at all. They all fail like this: 

> /usr/local/bin/ffmpeg -i ../slide-scan-res-grey slide-scan-res-RGB16.png

...
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fac7e808200] moov atom not found
../joop-ciago-grey8-8-OK.heic: Invalid data found when processing input

and similarly:

../joop-ciago-grey16-8-DIST.heic: Invalid data found when processing input
../joop-ciago-RGB8-8-OK.heic: Invalid data found when processing input
../joop-ciago-RGB16-12-OK.heic: Invalid data found when processing input

It shows --enable-libx265 in the configuration: 

built with Apple clang version 12.0.0 (clang-1200.0.32.21)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.3.1-with-options_6 --enable-shared --cc=clang --host-cflags= --host-ldflags= --enable-gpl --enable-libaom --enable-libdav1d --enable-libmp3lame --enable-libopus --enable-libsnappy --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-demuxer=dash --disable-libjack --disable-indev=jack --enable-opencl --enable-videotoolbox --disable-htmlpages
  libavutil      56. 51.100 / 56. 51.100
  libavcodec     58. 91.100 / 58. 91.100
  libavformat    58. 45.100 / 58. 45.100
  libavdevice    58. 10.100 / 58. 10.100
  libavfilter     7. 85.100 /  7. 85.100
  libswscale      5.  7.100 /  5.  7.100
  libswresample   3.  7.100 /  3.  7.100
  libpostproc    55.  7.100 / 55.  7.100

Testing with png input works fine, though. I must say that I am a bit puzzled whether or not ffmpeg is really working well for single image files, it seems to be entirely dedicated to processing video.

Luthien-in-edhil commented 3 years ago

And lastly, using heif-convert: converting the produced 12- and 8-bit .heic files back to PNG works great for the RGB ones, but fails for all greyscale ones: 

> heif-convert ../joop-ciago-grey8-8-OK.heic joop-ciago-grey8.png
File contains 1 images
libpng error: profile 'unknown': 'GRAY': Gray color space not permitted on RGB PNG
Error while encoding image
could not write image

But. When converting them to .jpg instead, all those work well - except for that slide-scan-res-grey16-8-DIST.heic (that looked stretched / interlaced in the preview / app) now produces an equally distorted jpeg. (I'll add them to the repository, folder heifconvert

Luthien-in-edhil commented 3 years ago

Re. config.log, I checked to see if there was anything to see there about the missing encoders.

configure:18743: libaom decoder: yes
configure:18745: libaom encoder: yes
configure:18747: rav1e encoder: yes
configure:18749: dav1d decoder: yes
configure:18751: libde265 decoder: yes
configure:18753: libx265 encoder: yes

though that does look ok. Do you have any idea why them might be unavailable?

farindk commented 3 years ago

@Luthien-in-edhil Thank you for providing the full set of test images. I've had a look at this and the cause of the issue was simply that my PNG loader code did not support 16bit greyscale images before. Hence, it was falling back to 8bit which resulted in the vertical stripes. I have now implemented the 16bit greyscale loader and it seems to work fine.

I still found one issue: when converting the HEIF back to PNG, heif_convert wants to save it as an RGB image, but the attached color profile is a greyscale profile. Hence, libpng complains about that. I don't have a solution for that yet. I'd have to implement a greyscale PNG writer first and then change the libheif pipeline such that is prefers to output greyscale instead of RGB.

Output to JPG works fine, but is reduced to 8 bit.

Luthien-in-edhil commented 3 years ago

@farindk Thanks a lot, I'll test it right away :) Do you maybe have an idea why the other encoders (rav1e, aom) aren't listed? Or should I open another issue for that?

farindk commented 3 years ago

rav1e and aom are AV1 encoders. They are for writing AVIF files, not for HEIF. You can see them when you switch to AVIF output: heif-enc -A --list-encoders

For HEIF, there is only x265.

Luthien-in-edhil commented 3 years ago

Ah, thanks. I hadn't realised that :$

And something else I was curious about: the build / make produces a this directory:

libheif/examples/.libs

which contains

>.libs $ la
total 808
-rwxr-xr-x  96K Nov 13 13:54 heif-convert*
-rwxr-xr-x  97K Nov 13 13:54 heif-enc*
-rwxr-xr-x  57K Nov 13 13:54 heif-info*
-rwxr-xr-x  65K Nov 13 13:54 heif-test*
-rwxr-xr-x  60K Nov 13 13:54 heif-thumbnailer*
-rwxr-xr-x  16K Nov 13 13:54 test-c-api*

though in the parent directory libheif/examples I see

-rwxr-xr-x  6.2K Nov 13 13:54 heif-convert*
-rwxr-xr-x  6.2K Nov 13 13:54 heif-enc*
-rwxr-xr-x  6.2K Nov 13 13:54 heif-info*
-rwxr-xr-x  6.2K Nov 13 13:54 heif-test*
-rwxr-xr-x  6.2K Nov 13 13:54 heif-thumbnailer*
-rwxr-xr-x  6.2K Nov 13 13:54 test-c-api*

I tried both versions of heif-enc yesterday and they seem to behave exactly the same, so where does the size difference come from?

farindk commented 3 years ago

The small files in libheif/examples are just short shell scripts, generated by the libtool part of the autoconf build system. They make sure that the executables are called with the correct library version in the build directory. The actual executable is in the .libsdirectory.

Try cat libheif/examples/heif-enc.

Luthien-in-edhil commented 3 years ago

ah, thanks thanks again!

Luthien-in-edhil commented 3 years ago

Just rebuilt the project and tested again with the same files. They all look good now.

When I look more closely, I noticed something that may be related to what you mentioned above. Looking at the produced .heic files; 

416K Nov 13 14:25 slide-scan-res-RGB16.heic
3.8M Nov 11 12:47 slide-scan-res-RGB16.png

435K Nov 13 14:25 slide-scan-res-RGB8.heic
972K Nov 11 12:50 slide-scan-res-RGB8.png

303K Nov 13 14:25 slide-scan-res-grey16.heic
1.3M Nov 11 12:50 slide-scan-res-grey16.png

323K Nov 13 14:25 slide-scan-res-grey8.heic
409K Nov 11 12:51 slide-scan-res-grey8.png

it struck me that the file sizes of the .heic images are a bit unexpected: the RGB16.heic (which is confirmed as 12 bits deep by Preview.app) is smaller in size than the RGB8.heic (reported as 8 bits deep). Both these are reported as having Profile Name: sRGB IEC61966-2.1

Also, the grey8.heic version is reported by Preview.app as being Colour model: RGB and so is the grey16.heic - and they are both reported as being 8 bits deep, so the 16-bit greyscale PNG one is not being converted to 12 bits. Despite the Colour model being RGB, they are both reported as having Profile Name: Greyscale D50

In case it's useful, I just uploaded those four files here

farindk commented 3 years ago

@Luthien-in-edhil Thanks for testing this so thoroughly. As I don't have a macOS to test this myself, this is very helpful.

Could you please check the attached file whether it is reported as greyscale, 8 bit on macOS?

grey8-with-mono-alpha-and-no-grid.heif.zip

farindk commented 3 years ago

And please also check the attached 12bit greyscale image. The heif is really 12bit and greyscale. I'm curious what macOS tells you about its format.

grey12-with-mono-alpha-and-no-grid.heif.zip

farindk commented 3 years ago

I have checked the four images images you encoded. The greyscale-8 image is really bits 8 and the greyscale-12 is also really 12 bits. It's strange that macOS thinks that they are RGB.

Maybe it's because the files use YUV for the alpha plane. Hence, I have changed this (5285369ed308179d91f615ee92e5cdfd2b5033f6). My images in the two comments above use greyscale alpha.

Luthien-in-edhil commented 3 years ago

I'm more than happy to help testing! Re. the 8 & 12 bit two greyscale images:

I can't open either one of those two. Preview comes with a popup saying "File cannot be opened, it may be damaged or use a file format that Preview doesn’t recognise". Affinity Photo even crashes when I try and open either one, and it generates an error report that includes this message:

validateTextureDimensions:1215: failed assertionMTLTextureDescriptor has height of zero.'`

I also tried using Krita, and that also refuses to open either one.

farindk commented 3 years ago

The problem with macOS is that even though they were to first support HEIF, their codec fails on so many perfectly valid images.

My guess is that the main question is how macOS saves the alpha images. Is there any way you can create an example HEIF image on macOS with an alpha channel? Maybe with Affinity Photo? An RGB image with alpha and a greyscale image with alpha (created with native macOS) would be great.

Krita also uses libheif internally, so I am not sure why it refuses to load them. Maybe an old version or it's using the native API on macOS.

Luthien-in-edhil commented 3 years ago

Just checked those images I created today in Affinity as well. I didn't expected it to open any 12-bit .heic files, but it does, though they come out in that same stretched / vertically interlaced way. What's odd is that Affinity reports all four files as RGBA/8bit, it even shows the separate channels.

With ImageConvert, I get this message

The image slide-scan-res-grey8.heic contains a grayscale color profile. But the image is in RGB color mode. So, the profile will be dropped. but the image opens perfectly OK. The 16 bit greyscale is more interesting even: it comes with the same profile warning, but the Info dialog says under "Color" that it's an RGB 24-bit image (so, 8 bits) - but the Exiftool reports the correct bitdepth (I'll just copy the whole output, maybe there's something interesting in there - I'll put the output for the RGB one in a next message if that contains anything interesting):

---- ExifTool ----
ExifTool Version Number: 12.09
---- System ----
File Name: slide-scan-res-grey16.heic
Directory: /Users/luthien/git/graphics/libheif-test/images/second-test
File Size: 303 kB
File Modification Date/Time: 2020:11:13 14:48:44+01:00
File Access Date/Time: 2020:11:13 17:51:22+01:00
File Inode Change Date/Time: 2020:11:13 17:59:09+01:00
File Permissions: rw-r--r--
---- File ----
File Type: HEIC
File Type Extension: heic
MIME Type: image/heic
Image Width: 1024
Image Height: 650
---- QuickTime ----
Major Brand: High Efficiency Image Format HEVC still image (.HEIC)
Minor Version: 0.0.0
Compatible Brands: mif1, heic
Handler Type: Picture
Auxiliary Image Type: urn:mpeg:hevc:2015:auxid:1
HEVC Configuration Version: 1
General Profile Space: Conforming
General Tier Flag: Main Tier
General Profile IDC: Format Range Extensions
Gen Profile Compatibility Flags: Format Range Extensions
Constraint Indicator Flags: 0 0 0 0 0 0
General Level IDC: 93 (level 3.1)
Min Spatial Segmentation IDC: 0
Parallelism Type: 0
Chroma Format: Monochrome
Bit Depth Luma: 12
Bit Depth Chroma: 12
Average Frame Rate: 0
Constant Frame Rate: Unknown
Num Temporal Layers: 1
Temporal ID Nested: Yes
Image Spatial Extent: 1024x650
Image Pixel Depth: 12
Media Data Size: 308904
Media Data Offset: 1165
---- Meta ----
Primary Item Reference: 4
Meta Image Size: 1024x650 0 0 1024 650
---- ICC-header ----
Profile CMM Type: Little CMS
Profile Version: 4.3.0
Profile Class: Display Device Profile
Color Space Data: GRAY
Profile Connection Space: XYZ
Profile Date Time: 2020:11:09 20:35:53
Profile File Signature: acsp
Primary Platform: Apple Computer Inc.
CMM Flags: Not Embedded, Independent
Device Manufacturer: 
Device Model: 
Device Attributes: Reflective, Glossy, Positive, Color
Rendering Intent: Perceptual
Connection Space Illuminant: 0.9642 1 0.82491
Profile Creator: Little CMS
Profile ID: 0
---- ICC_Profile ----
Profile Description: Greyscale D50
Profile Copyright: No copyright, use freely
Media White Point: 0.9642 1 0.82491
Gray Tone Reproduction Curve: (Binary data 16 bytes, use -b option to extract)
---- Composite ----
Image Size: 1024x650
Megapixels: 0.666
Luthien-in-edhil commented 3 years ago

Continuing with ImageConverter (most recent version as per today)

The RGB/8 opens without any comment and the Exiftool seems to be correct everywhere. The RGB/16 is also interesting: while the greyscale/16 was reported as an RGB 24-bit image, the RGB/16 is reported as RGB 48 bits (in the "Image" tab of the Info dialog), though again the Exiftool is correct: 

---- ExifTool ----
ExifTool Version Number: 12.09
---- System ----
File Name: slide-scan-res-RGB16.heic
Directory: /Users/luthien/git/graphics/libheif-test/images/second-test
File Size: 416 kB
File Modification Date/Time: 2020:11:13 14:25:03+01:00
File Access Date/Time: 2020:11:13 17:50:23+01:00
File Inode Change Date/Time: 2020:11:13 18:09:01+01:00
File Permissions: rw-r--r--
---- File ----
File Type: HEIC
File Type Extension: heic
MIME Type: image/heic
Image Width: 1024
Image Height: 650
---- QuickTime ----
Major Brand: High Efficiency Image Format HEVC still image (.HEIC)
Minor Version: 0.0.0
Compatible Brands: mif1, heic
Handler Type: Picture
Auxiliary Image Type: urn:mpeg:hevc:2015:auxid:1
HEVC Configuration Version: 1
General Profile Space: Conforming
General Tier Flag: Main Tier
General Profile IDC: Format Range Extensions
Gen Profile Compatibility Flags: Format Range Extensions
Constraint Indicator Flags: 0 0 0 0 0 0
General Level IDC: 93 (level 3.1)
Min Spatial Segmentation IDC: 0
Parallelism Type: 0
Chroma Format: 4:2:0
Bit Depth Luma: 12
Bit Depth Chroma: 12
Average Frame Rate: 0
Constant Frame Rate: Unknown
Num Temporal Layers: 1
Temporal ID Nested: Yes
Image Spatial Extent: 1024x650
Image Pixel Depth: 12 12 12
Media Data Size: 424639
Media Data Offset: 1375
---- Meta ----
Primary Item Reference: 4
Meta Image Size: 1024x650 0 0 1024 650
---- ICC-header ----
Profile CMM Type: Apple Computer Inc.
Profile Version: 4.3.0
Profile Class: Display Device Profile
Color Space Data: RGB
Profile Connection Space: XYZ
Profile Date Time: 2020:11:11 12:47:17
Profile File Signature: acsp
Primary Platform: Apple Computer Inc.
CMM Flags: Not Embedded, Independent
Device Manufacturer: Apple Computer Inc.
Device Model: 
Device Attributes: Reflective, Glossy, Positive, Color
Rendering Intent: Perceptual
Connection Space Illuminant: 0.9642 1 0.82491
Profile Creator: Apple Computer Inc.
Profile ID: 0
---- ICC_Profile ----
Profile Description: sRGB IEC61966-2.1
Profile Copyright: Copyright Apple Inc., 2020
Media White Point: 0.9642 1 0.82491
Red Matrix Column: 0.43604 0.22249 0.01392
Green Matrix Column: 0.38512 0.7169 0.09706
Blue Matrix Column: 0.14305 0.06061 0.71391
Red Tone Reproduction Curve: (Binary data 32 bytes, use -b option to extract)
Chromatic Adaptation: 1.04788 0.02292 -0.05022 0.02959 0.99048 -0.01707 -0.00925 0.01508 0.75168
Blue Tone Reproduction Curve: (Binary data 32 bytes, use -b option to extract)
Green Tone Reproduction Curve: (Binary data 32 bytes, use -b option to extract)
---- ICC-chrm ----
Chromaticity Channels: 3
Chromaticity Colorant: Unknown (0)
Chromaticity Channel 1: 0.64 0.33
Chromaticity Channel 2: 0.3 0.60001
Chromaticity Channel 3: 0.14999 0.06
---- Composite ----
Image Size: 1024x650
Megapixels: 0.666
farindk commented 3 years ago

It's a complete mess how these are handled in macOS. I think it would really help most if you could send me some files from native macOS, RGB and greyscale, with alpha channel. Then I'll simply mimic their structure.

Luthien-in-edhil commented 3 years ago

Sure. What format do you want? And both 8 and 16 bits?

farindk commented 3 years ago

Thank you. If it's not too much work: all combinations of

i.e. 4 images.

How do you create them? With Affinity Photo? If yes, please check whether they can be read by Preview.

Luthien-in-edhil commented 3 years ago

I think I just misunderstood - you mean you want native mac .heic files? That's possible but I can then only give you an 8-bit one, because I cannot create 12-bit heic files natively (that's why I tried libheif).

Luthien-in-edhil commented 3 years ago

Affinity can also produce only 8-bit heic files, as GraphicsConverter. But GraphicsConverter has support for 12-bit heic planned soon (or so they told me).

farindk commented 3 years ago

Can Affinity do alpha channels? That's actually the largest unknown for me at the moment.

So if you could do an RGB and a greyscale, both 8 bit, both with alpha channel, that would also be a good start.

Luthien-in-edhil commented 3 years ago

Yes, Affinity does that, and Preview as well. I can even choose in Preview whether or not to include the alpha channel when exporting to (8 bit) heic. I just uploaded RGBA and greyscale + alpha heic files here, the 16-bit png originals are also there

Luthien-in-edhil commented 3 years ago

just added non-alpha versions in case you'd like to compare them

(will be afk for a bit now, but will check back within an hour or so)

farindk commented 3 years ago

Both, your greyscale and your RGB files are RGB internally. The only difference is that on the greyscale image, the color profile was removed.

Notes for me: Image itself is RGB, Alpha channel is monochrome. Image and Alpha as two separate grid compositions, Alpha as aux referring to Image. Pixi only assigned to grid composition (8,8,8 for image, 8 for alpha).

Luthien-in-edhil commented 3 years ago

If you need help testing in the future just let me know!

Luthien-in-edhil commented 3 years ago

Update about Big Sur: unfortunately I cannot view the 12 bit/channel heif images any longer in the preview app. They show up completely blank (white).

Luthien-in-edhil commented 3 years ago

I did some testing for what it's worth:

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [8642]

VM Regions Near 0x7fb41eb27001:
    MALLOC_LARGE             7fb418000000-7fb41eb27000 [107.2M] rw-/rwx SM=PRV  
 --> 
     MALLOC_MEDIUM            7fb420000000-7fb420800000 [ 8192K] rw-/rwx SM=PRV  

Application Specific Information:
dyld2 mode

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   heif-enc                        0x000000010b092c77 loadPNG(char const*, int) + 1191 (heif_enc.cc:738)
1   heif-enc                        0x000000010b094fc0 main + 3072 (heif_enc.cc:1200)
2   libdyld.dylib                   0x00007fff2033f631 start + 1
...
...
-[MTLTextureDescriptorInternal validateWithDevice:]:1248: failed assertion `Texture Descriptor Validation
MTLTextureDescriptor has height of zero.
...