This is for convenience. We're already ignoring whether it does or does
not have the NUL. Since having binary characters is likely an
undesireable flaw in the image and support for binary characters by EXIF
is probably just a vestigial, ridiculous feature, just stop short and
return the preceding characters if encountered. If we do actually need
the binary at some point in the future, we can circle back and
potentially add an option to do so.
Closes#55
- 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
add translate to type cases
replace float compare by Nextafter and Nextafter32
add parser for floats and doubles
add float and double parsers
add support for doubles and floats in FormatFrom functions
add ReadFloats and ReadDoubles for context
add float32 and double encoder
merging
merge
add float and double parsers
add ReadFloats and ReadDoubles for context
add float32 and double encoder
removing log alias from parser
removing log alias from parser_test
removing log alias from type
removing log alias from type_test
removing log alias from value_context
removing aliases from value_contex_test
removing log alias from value_encoder
removing log alias from value_encoder_test
update parser slices from floats and doubles
merge
update values for tests
raise exception when parsing with different expected size
NewIfdMappingWithStandard and related (in ifd.go). We now use the same
functions in common/.
- NewIfdMappingWithStandard now returns an error, too.
This took care of several backwards-incompatible tasks that have been
waiting on v3 to be forked.
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
Wendel Hime