This was a recently introduced, preexisting bug caused by adding support
for multiple types for certain tags. This suddenly became an issue when
we added all remaining additional types and at least one of these was in
our testing data.
Apparently PixelXDimension and PixelYDimension can official be a SHORT
*or* a LONG, and, now that we're skipping anything that doesn't agree
with the index, it broke some tests.
This also mitigates the processing of duplicate tags (which should never
occur) if the duplicate tags also happen to have unexpected types (our
current scenario).
2020/05/17 02:26:37 exif.ifd_enumerate: [DEBUG] IFD [IFD/GPSInfo] tag-count: (10)
2020/05/17 02:26:37 exif.ifd_enumerate: [WARNING] Skipping tag [IFD/GPSInfo] (0x0005) [GPSAltitudeRef] with an unexpected type: (5) [RATIONAL] != (1) [BYTE]
2020/05/17 02:26:37 exif.ifd_enumerate: [WARNING] Skipping tag [IFD/GPSInfo] (0x001b) [GPSProcessingMethod] with an unexpected type: (2) [ASCII] != (7) [UNDEFINED]
2020/05/17 02:26:37 exif.ifd_enumerate: [DEBUG] Next IFD at offset: (00000000)
Fixes#37
- This resulted in the lookup table having unique entries, and therefore
no longer needing its values to be slices. We are going to fix this.
It is not a backwards-compatible change, but this is a fairly internal
internal functionality.
- Add simple accessors to determine if a thumbnail offset or size.
- Invalid tag-type sets the tag-ID so that we can include it in the log.
- Other logging enhancements.
- Removed newline
- Incorporate the thumbnail into the furthest-offset counter.
- Thumbnail() no longer panics ErrNoThumbnail and just returns it.
- This is a managed error, not a true panic condition.
- Collect() now builds index with FQ IFD paths, not non-FQ.
We were not qualifying our thumbnail tag checks with the IFD that
thumbnails are supposed to live in, and were trying to parse the tags
that happen to share the same tag-IDs as thumbnails.
Fixes #dsoprea/go-jpeg-image-structure/issues/10
We now keep track of the further offset that we have accessed (though
not necessarily the furthest offset of data that is unparseable by us).
It sometimes supports debugging efforts to have a ballpark idea of how
much EXIF data there is, rather than just "from the signature to the
end of the file" or however big the EXIF container is in the enclosing
image format. The latter can be buggy or ambiguous.
