Tip of dependency is broken and it was affecting us:
https://github.com/go-errors/errors/issues/27
- We also disabled 1.10 and 1.11 due to lack of support in dependencies now that we're being recognized as a module.
if `Decode()` returns `exifcommon.ErrUnhandledUndefinedTypedTag` it just
falls through, but should have been returning
`exifundefined.ErrUnparseableValue`.
- Also, `GetRawBytes()` was missing the recover clause for blanket error
handler.
In lieu of dropping in next release. We needed this in order to write
some unit-tests for exifcommon functionality, and this is common
functionality anyway (by any definition of common thus far).
- common/ifd.go: Added NewIfdIdentityFromString. The above allowed us to
cover this with unit-tests.
- This was required for go-exif-knife, to get IFD-paths from the
command-line.
- utility.go: Add GetExifData() to return flat tags and extra data and
to allow guessing of tags for misplaced IFDs.
- exif-read-tool/main.go: Implement tag guessing
2020/05/25 19:21:33 exif.utility: [WARNING] Tag with ID (0x0201) in IFD [IFD/Exif] is not recognized and will be ignored.
2020/05/25 19:21:33 exif.utility: [WARNING] (cont'd) Tag [JPEGInterchangeFormat] with the same ID has been found in IFD [IFD] and may be related. The tag you were looking for might have been written to the wrong IFD by a buggy implementation.
2020/05/25 19:21:33 exif.utility: [WARNING] Tag with ID (0x0202) in IFD [IFD/Exif] is not recognized and will be ignored.
2020/05/25 19:21:33 exif.utility: [WARNING] (cont'd) Tag [JPEGInterchangeFormatLength] with the same ID has been found in IFD [IFD] and may be related. The tag you were looking for might have been written to the wrong IFD by a buggy implementation.
Closes#38
This allows us to pass around individual tokens that we can use to
generate IDs, names, and qualified and non-qualified IFD paths, rather
than [necessarily] having to pass or store them individually.
The previous global variables were strings. Now they are IfdIdentity structs
and have been renamed to be more accurate (in general, as well as for this).
The previous variables have been kept but are now just assigned to the newer
variables. This is backwards-compatibility that will be removed in the future.
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.
Dustin Oprea