EXIF data is prefixed with garbage

[dsoprea]

I'm finding the EXIF data to be unparseable unless the parse is preceded by a brute-force search to first identify where the EXIF data actually starts. You're currently using github.com/rwcarlsen/goexif/exif to parse your EXIF data in dumpheif.go, and I'm assuming that it does this search automatically.

I'm using go-exif to parse it. Specifically, the Collect. This expects the EXIF blob to start at offset (0). I got this on my attempt:

=== RUN   TestHeicExifParser_Parse
--- FAIL: TestHeicExifParser_Parse (0.00s)
panic: no exif data [recovered]
	panic: no exif data

When I dumped the first few bytes of what is being returned by EXIF(), I see this:

=== RUN   TestHeicExifParser_Parse
DUMP: 45 78 69 66 00 00 4d 4d 00 2a 00 00 00 08

So, now it makes sense. 4d 4d 00 2a 00 00 00 08 (offset 6) is where the EXIF data starts (the byte-order bytes, 0x4d 0x4d, followed by the fixed-byte signature, 0x00 0x2a, followed by the typical first-IFD offset 0x00 0x00 0x00 0x08).

ISO 23008-12 (the HEIF/HEIC specification), Section A.2.1 ("Untimed Exif metadata"), looks like it might deal with this. There's a exif_tiff_header_offset property of the ExifDataBlock type that species the offset where the EXIF data actually starts within the EXIF stream:

I'm not sure of your actual EXIF implementation, though. I did a couple of hasty string searches but couldn't seem to find anything that corresponded to a similar type/structure in your code.

Using another go-exif function, SearchAndExtractExif, we are able to skip past those first few garbage bytes at very little cost and are able to parse. It'd be cool if you can look into this, though.

Thanks