6 Commits (d19e38a7236c421f436c496041aaf872c8b4cc24)

Author	SHA1	Message	Date
Dustin Oprea	d19e38a723	backwards incompatible: ifd_enumerate.go: Drop fqIfdPath and ifdIndex from visitor function signature	2020-07-11 13:15:18 -04:00
Dustin Oprea	f2c3d1c0ec	backwards incompatible: ifd_enumerate.go: Stop exporting Ifd fields ... Finally.	2020-07-11 13:15:18 -04:00
Dustin Oprea	7ca1c7b13e	backwards incompatible: GetFlatExifData(), Scan(), and Visit() all take a ScanOptions struct now	2020-07-11 13:15:18 -04:00
Dustin Oprea	83b844408c	backwards incompatible: Stop exporting ParseOneIfd and ParseOneTag	2020-07-11 13:15:18 -04:00
Dustin Oprea	312218d7b1	Use encapsulated data/reader rather than bytes ... 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	2020-07-11 12:12:48 -04:00
Dustin Oprea	56058635d0	Seed v3 release. Copy from v2 release.	2020-07-11 12:12:48 -04:00