This reverts commit c23f7a10661b5308af9619b5d577a1754acf8412.
The package-path will be a build-path rather than a source-path, and any
assets being referred to will not be found.
This reverts commit 77cb76cd34b585821d04892f166ac4a126d0cf3e.
The package-path will be a build-path rather than a source-path, and any
assets being referred to will not be found.
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
