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
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
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