This reverts commit 4f2f9044e60d16b189cd13acf41089dd83c79c0e.
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.
Per our recent change to deimplement ITEVRs.
- ifd_enumerate_test.go: Fixed some test naming.
- ifd_builder_test.go: Dropped some now-unnecessary implementations of
ITEVRs.
This was an early way of resolving tag values that is now obsolete.
`ValueContext` structs should be used, and these, in many cases, should
be able to be constructed from the current context without passing
additional arguments.
- ifd_builder_test.go: Refactors to several tests due to loss of ITEVR support.
- ifd_builder_encode_test.go: Moved test-IB populate to testing_common.go .
- ifd_builder.go: Fixed test naming (in most cases, omitted type name).
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.
Added a `Size()` method to it and decommissioned redundant
`TagTypeSize()` and `(TagType).Size()`.
- ifd_enumerate.go: Moved `ValueContext` definition to
value_context.go .
- 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.
- 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.
- ..to use the word "Standard" instead, instead of having both.
- Removed original NewStandardBuilderTag function. Just used by a couple
of tests and it conflicts with one of the renamings.
- It's probably a generally good idea.
- These are usually created by other methods, but they're regularly
interacted with when you want to make tag changes and by making them
private we can't public official, testable examples.
- Corrected names for new examples.
- We added a trick to overcome the fact that the tag is a slice of longs
rather than bytes (and would usually cause check errors and alignment
problems), but this allows us to use the normal allocation and
decoding flows that are used by normal tags.
- Made things simpler, but we're still mis-encoding the
thumbnail, somehow/somewhere.
- ifd_builder_encode
- Bugfix: We were assigning the "next" IFD in correctly (so, chaining
was broken).
- Bugfix: We weren't using the right value when *writing* the "next"
IFD offset (so, chaining was, again, broken).
- The same IFD was showing as both a child and a sibling, so we were
seeing the EXIF IFD also being chained-to by the first root IFD
instead of the *actual* sibling, but only after encoding and then
decoding (so, this had to be tracked down in the encoding
semantics, which was non-trivial).
- Added a test for the stuff that we fixed.
- Implemented journaling, where we can dump a hierarchically-formatted
list of operations involved in a completed encode.
- ifd_enumerate: Added (Ifd).TagValueBytes() to return the raw tag-
value's bytes (rather than just having (Ifd).TagValue(), which returns
the value marshaled into a string). Good for comparing raw encoded
and decoded values without imposing interpretation (which gets us into
trouble with unknown-type tags whose values are non-standard and
undocumentedand, therefore, not actually parseable).
- Rewired a lot of print and dump functions.
- For naming-specificity as well as functionality.
- Removed from debugging.
- Big step. This is the most complicated thing we can do.
- ifd_builder_encode: Need to debug encoding linked IFDs to EXIF.
- ifd_builder: Renamed `SetNextIfd()` to `SetNextIb()`.
- ifd_builder: Bugfix to size assertion on return of
(IfdBuilderEncode).encodeIfdToBytes().
- ifd_enumerate: Rename PrintNode() to PrintTree().
- ifd_enumerate: Added DumpTree() (to return a list of strings).
- ifd_enumerate: Added utility functions to parse individual, encoded
IFDs and tags.
- ifd_builder: Corrected `NewBuilderTagFromConfig()` to automatically
encode whichever type of value-argument it gets.
- 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).
- Using an interface{} required us to validate the encapsulated type or
risk forgetting to.
- AddTagsFromExisting now just copies the bytes verbatim if no value-
resolver provided.
- ifd_builder:
- We now validate that `builderTag` instances are either a byte array
or a child Ifd before allowing to add.
- Renamed `builderTag.valueBytes` to `builderTag.value` (it's not
necessarily bytes).
- `builderTag` now gets the child IFD name if representing a child
IFD.
- Added ability to dump structure to string slice.
- Added NewIfdBuilderFromExistingChain to reconstruct whole chain
from a read IFD chain (collection).
- Wrote IB dumper.
- Added structural tests.
- Moved ifd_tag_entry types to separate file.
- tags_unknown: Unknown-type tags can now satisfy the `UnknownTagValue`
interface to return `[]byte`.
- `IfdTagEntry.ValueBytes` automatically uses this. Else, error if not
`[]byte` or `string`.
- ifd_enumerate
- Now embed `ByteOrder` in `Ifd` (we otherwise require it to be passed
a bit too often).
- Renamed some occurences of "IFD" to "IB" where an actual IB in order
to not be confusing.
- 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).
