Dr. Neal Krawetz

@farindk I'm seeing the crash with old and new libraries. Tested: Set1: "libaom.so.3.0.0", "libde265.so.0.1.1", "libx265.so.200", "libheif.so.1.11.0" (really old) Set2: "libaom.so.3.3.0", "libde265.so.0.1.1", "libx265.so.201", "libheif.so.1.12.0" (old) Set3: "libaom.so.3.6.0", "libde265.so.0.1.4", "libx265.so.207", "libheif.so.1.15.1" (new/current)...

Oh interesting... libheif/examples/ heif-info, heif-convert both work (no crash). Looks like the problem may be in how my code is calling the library. (Diving deeper.)

Oh, I found the problem. The ispe says the image should be 1280x4439. However, the decoded image from heif_decode_image() is 1280x854. (I'm trying to copy 1280x4439, so it fails.) I'm...

Without ispe, how do you recommend/propose tools like ExifTool identify the image size without rendering the image?

@bigcat88 The corrupt image isn't mine, so I cannot give permission. It was an upload to FotoForensics.com. The ToS at FotoForensics says that all images can be used for research....

@silverbacknet wrote: > As far as I can tell, if there are any transforms beyond a simple crop, you basically have to run the entire compositing engine anyway to obtain...

> start at the ispe box That's the problem. In the crash poc file, the ispe does not match the decoded image dimensions.

`Is this [image](https://github.com/bigcat88/pillow_heif/raw/master/tests/images/heif_special/guitar_cw90.hif) satisfy HEIF standard?` Cool! I haven't seen a HEIX file before. And 16-bit depth! Looks valid to me. The ispe matches the image dimensions before transformations (rotation).

As I understand the JPEG standard (itu-t81), an APP block cannot appear in the image stream (ffda to ffd9). The image stream can only contain restart tags (ffd0 - ffd7)...

Can you give more details about this issue?