- This will allow tags to be matched from any IFD if not found in the
primary and to go with whatever type is encoded into the tag even if
it disagrees with what is officially supported.
Supports https://github.com/dsoprea/go-exif/issues/53
- ifd_enumerate.go
- Bugfixes for various broken log messages.
- Bugfix for ErrTagNotFound not actually skipping.
- common/parser.go: Parsing ASCII now panics if there's binary (8-bit)
characters.
- utility.go: GetFlatExifData() just logs and skips these.
- exif.go: Add searchAndExtractExifWithReaderWithDiscarded(), to return
how many bytes it seeks through.
Supports https://github.com/dsoprea/go-exif/issues/53
This should mitigate most issues where the same tag appears multiple
times with different types. This happens more than you would think that
it would.
- ErrTagTypeNotValid is now returned unwrapped.
- This is typically the convention for static error messages.
https://github.com/photoprism/photoprism/issues/431
Given a stream of data, it is possible to determine the beginning of
EXIF data but not the end. Therefore, either an image-aware
implementation must know how to parse an image and extract the EXIF
data or a brute-force search implementation (one of which is provided
by this project) must find the start anchor and then return all bytes
from that to the end of the file.
We have been made aware of some use-cases where a brute-force search
might be unavoidable due to trust or stability issues with the image
structure. This leads to large allocations. This can be avoided by
accomodating support that will allow for both a byte-slice or an
`io.ReadSeeker`. Since the EXIF structure is typically not read-
intensive (a couple of kilobytes if no thumbnail is present), this
should have a minimal performance impact.
Closes#42
Dustin Oprea