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.
- Added `SearchAndExtractExifWithReader()`.
- `SearchFileAndExtractExif()` now calls `SearchAndExtractExifWithReader()`
instead of reading the whole image first.
Fixes#34
Relates to optimizations in df264b3 as well.
We've encountered a malformed user-comments value in an image from a
Canon EOS 5D Mark II.
2020/05/02 16:28:58 exifjpeg.ifd: [DEBUG] Parsing IFD [IFD/Exif] (0) at offset (0102).
2020/05/02 16:28:58 exifjpeg.ifd: [DEBUG] Current IFD tag-count: (33)
2020/05/02 16:28:58 main.main: [WARNING] Skipping unparseable undefined tag: [IFD/Exif] (9286)
2020/05/02 16:28:58 exifjpeg.ifd: [DEBUG] Descending to IFD [IFD/Exif/Iop].
2020/05/02 16:28:58 exifjpeg.ifd: [DEBUG] Parsing IFD [IFD/Exif/Iop] (0) at offset (a164).
Fixes#33
It turns out that there is so much loose handling with the terminating
NUL characters out there that there's a societal breakdown without this.
Fixes#31
That, rather than just a couple of values from it. Primarily because we
want to not have callers involve themselves with the value context
unless they want to.
- ifd_tag_entry.go: ITEs now provide `Format()` and `FormatFirst()`
methods.
- We dumped several spots of code that could just reuse functions to
format, decode, or get raw bytes rather than dealing with undefined
vs not undefined logic themselves.
- This is now possible due to prior change.
- ifd_tag_entry.go: No longer exports GetValueContext(). Users shouldn't
usually have to touch it, now.
- Added some commenting.
This commit almost represents everything we have been trying to achieve,
now made possible by the last several commits.
They'll also now embed all of the information they need to know since it
is all known where the ITEs are created. This prevents the user from
having to be involved in it. This makes it much more straightforward and
enjoyable to use.
- ifd_tag_entry.go
- newIfdTagEntry now takes and embeds `addressableBytes` and
`byteOrder`.
- We've dumped the `value` member that let the caller preload a parsed
value (or bytes?). It's no longer necessary since this led to
inconsistencies and the ITE can produce these values directly, now.
- `Value()` obviously no longer takes `addressableValue` and
`byteOrder` since now embedded.
- `Value()` will now see and return ErrUnhandledUnknownTypedTag
directly (not wrapping it, since this is a handled case).
- common/type.go: FormatFromType now uses Stringer as a fallback if
possible. All undefined-tag wrapper types implement it, so the same
function can handle both undefined and non-undefined values, and the
individual types can control the strings presented in simple listing.
- Dropped "resolveValue" parameters from all of the collect, visit, and
parsing functions. Resolution is now a later step performed by the
caller on the ITEs, directly.
- This parameter was protection against undefined-type values
disrupting simple enumeration, but now the user can simply produce
the list of tags and can either choose to decode their value or not,
directly. If they do, they, as of earlier, recent commits, also have
the ability to properly manage unhandled undefined-values so they
don't crash.
- The ITEs can now create ValueContext structs directly
(GetValueContext()), though it might not be necessary now that the
ITEs can produce the values and encodings directly.
- This also allowed us to dump several other GetValueContext()
implementations elsewhere since it is now self-reliant on this type
and those methods were essentially kludges for the lack of this.
- Dump a bunch of "Value" methods from ITEs which just weren't useful or
simple enough. Replaced by the above.
- Fixed `(Ifd).String()` to have a pointer receiver.
Dustin Oprea
Dustin Oprea