This reverts commit 4f2f9044e6.
Reintroduces errors from `UndefinedValue()` when the undefined-type is
unhandled.
- We now just return it rather than panic with it so that we can check
for it directly rather than use `log.Is()`.
- We've updated the checks across the code accordingly.
The upshot of this is that generating a list of type-correct slices or a
string from a tag's value is now stupidly easy.
- Broke parsing into an independent type (parser.go:Parser).
- Moved primary value-processing logic to `ValueContext` so that it
coexists with the actual data (though as much basic functionality as
possible is implemented independently and reused here). This
eliminates extremely ridiculously obtuse usage procedure.
- Deprecated almost all existing TagType functionality (in order to
distance us from this now-legacy usage pattern). Existing
functionality maintained for now. We'll drop it when we do the next
release major.
- `ValueContext` is now passed by reference.
- ifd_builder.go
- `BuilderTag` now embeds `ByteOrder`.
- `BuilderTag` `String()` now prints value.
- type.go
- `TagType` `ValueIsEmbedded()` renamed to `valueIsEmbedded()`.
- Add `readRawEncoded()` method to `TagType`.
- Add `Format()` method to `TagType` to isolate code for processing
output strings for all types.
- This will also print a suffixing ellipsis when `justFirst` is
`true`.
- Important bugfix for embedded values always being presented as
four-bytes rather than being truncated to their reported unit-count
bytes first. We tripped over this when some of our corresponding
math was found to be wrong elsewhere.
- Minor reformatting.
- tags_unknown.go: Unhandled unknown values are now wrapped in a
TagUnknownType_UnknownValue rather than returning an error. This is
now used to print byte-counts and SHA1s for unhandled values.
- tags_unknown.go: UnparseableUnknownTagValuePlaceholder now has message
"!UNKNOWN" rather than "!UNPARSEABLE".
- These are absolute representations of where an IFD is positioned with
respect to the other IFDs. There is a more-specific, "fully-qualified"
form of the IFD-path that allows you to express indices in order to
refer to specific siblings.
- Eliminates issues with IFDs at different levels potentially having the
same name (if that's what is required with a certain dataset/
datasource).
- There is a specific IFD registry that controls the heirarchy of IFDs
that we recognize and the tags associated with the child IFDs. This
allows custom hierarchies replacing even the TIFF specification for
which are expected in an image (so we can read other types of images
or any potential IFD hierarchy, even non-image ones).
- IFD and IB instances embed the IFD-path and FQ IFD-path that they were
found or built for.
- Updated IfdByteEncoder tests to use it instead of hacking-together
their own BT's (makes for more standardized, consistent testing).
- Universally refactored all core IFD knowledge implemented upon a
single IFD name to instead work with IfdIdentity instances, instead,
in order to validate that we only recognize the IFDs only in the
context of the correct parents in the hierarchy.
- Implemented standard testing byte-order (assigned to
TestDefaultByteOrder).
- Added some assertions and constants. Renamed from variable so it'd be easy to
tell if the byte-arrays, even though they come directly from the EXIF, which
specific offsets they start at (so no remove for confusion during enumeration
and building).
Dustin Oprea
Dustin Oprea