exifView follows only the Exif sub-IFD pointer 0x8769 (internal/adapter/scanner/metaview.go:161-166) and never the MakerNote 0x927c, so a camera owner's name a vendor writes there (Canon's MakerNote tag 0x0009 OwnerName, in the TIFF byte order with header-relative offsets) is not read as a person tag: a short single-token owner name in a JPEG's or TIFF's Canon MakerNote is dropped as chance. A name of eight or more bytes, or one of several words, is still caught by the raw ASCII scan. Found by review-scanMeta (fixture 'Canon MakerNote OwnerName' scans clean at the integration tip).

exifView follows only the Exif sub-IFD pointer 0x8769 (internal/adapter/scanner/metaview.go:161-166) and never the MakerNote 0x927c, so a camera owner's name a vendor writes there (Canon's MakerNote tag 0x0009 OwnerName, in the TIFF byte order with header-relative offsets) is not read as a person tag: a short single-token owner name in a JPEG's or TIFF's Canon MakerNote is dropped as chance. A name of eight or more bytes, or one of several words, is still caught by the raw ASCII scan. Found by review-scanMeta (fixture 'Canon MakerNote OwnerName' scans clean at the integration tip).

Grounds

• pursued: a short single-token OwnerName in a Canon MakerNote (either byte order, a moved block with its footer, a CR2-shaped TIFF, a CR3 CMT3 box) and a short Artist on a TIFF's second page are reported as real_name, while a short name in another Canon tag, another vendor's MakerNote or a malformed block is not; any of those outcomes differing in makernote_test.go or TestEXIFNextIFDIsRead, or a fuzz crash in FuzzCanonMakerNote, would show it wrong